Asynchronous Sending

Asynchronous sending is the flow used for deferred-processing documents: daily sales-ticket summaries, void communications and reversals. Unlike synchronous sending, the OSE does not return the CDR immediately — it returns a ticket that the issuer must use later to query the processing result.

Step by step

1. Sending the summary (Issuer → OSE)

The issuer generates the XML of the summary or void communication, signs it with its digital certificate, compresses it into a ZIP file following the file naming convention, and sends it to the OSE via the sendSummary method.

2. Receiving the ticket

The OSE validates the submission (authentication, file format, XML schema) and, if the document is accepted for processing, returns a ticket — a unique identifier for the asynchronous process. This ticket does not mean the document has already been accepted by SUNAT: it only confirms that the OSE received it and is processing it.

3. Deferred processing (OSE → SUNAT)

In parallel, the OSE forwards the summary or communication to SUNAT for processing. SUNAT evaluates each receipt included in the summary and generates the corresponding CDR. This processing is not immediate — it may take minutes or hours depending on SUNAT's load.

4. Querying the result (Issuer → OSE)

Once the issuer has the ticket, it must periodically query the process status via getStatus, sending the ticket received in step 2.

While the process is still in progress, getStatus returns the statusCode 98 (in process). The issuer must keep querying until it receives a different statusCode:

• If the process finished correctly, getStatus returns the CDR of the summary in Base64.
• If the process finished with an error, getStatus returns the corresponding error code and message.

When to use this flow?

Use asynchronous sending for daily sales-ticket summaries, void communications and reversal summaries — documents that group multiple receipts or that SUNAT processes in batch. For an invoice, individual sales ticket, note or DAE, use synchronous sending.

Wait time between queries

There is no fixed guaranteed processing time on SUNAT's side. It is recommended to implement a retry mechanism with incremental waiting (for example, querying every 60 seconds) instead of querying getStatus continuously.