The Spanish version is the authoritative reference. View in Spanish

🇵🇪 Peru

This sheet assumes you know the xPOS-Core communication protocol. Here we only document what is specific to Peru.

New country in version 2.7.0

Peru joins the xPOS family in xPOS-Core 2.7.0, with the same principles of the platform: the sale never stops, and operation with several issuers on the same device is available from day one.

Response and contingency renewed in version 2.7.1

Since xPOS-Core 2.7.1, the response's HTTP code tells the POS what to do, only what never reached the tax authority is queued, xPOS recovers the document when the POS resends the same number, invoices in contingency are resent automatically, and the response carries the SUNAT QR.

Summary

Aspect	Value
`country` code	`pe`
Tax authority	SUNAT, directly or through the OSE Gosocket
Pattern	A — XML with XSD
Channel	REST only (`POST /api/v1/process-documents`). There is no WebSocket integration
Supported `inputType`	`json`, `xml`, `txt`, `xdoc`
Numbering	The POS sets the series and the correlative: xPOS does not assign a folio
Output	Signed tax XML (UBL 2.1), with the SUNAT QR
Contingency	Only what never reached the tax authority: receipts (boletas) to the Daily Summary, invoices to automatic resending

What is specific to Peru: what xPOS returns to the POS according to the HTTP code, resending the same number, contingency and its deadlines, the Daily Summary, the regularized paper receipt and the printed representation QR.

Peru follows the xPOS synchronous flow: the tax authority's verdict arrives in the same call, and the POS receives 200 deliver, 503 retry now, 510 fix and retry or 400 not issued. Details in What xPOS returns to the POS.

🔀 Destination by document type: SUNAT or OSE

Peru supports two destinations for the same document: direct SUNAT or the OSE (Electronic Services Operator) Gosocket. Both return the Receipt Confirmation (CDR) in the same call: the destination and the credentials change, not the contract with the POS.

How the destination is configured

The destination is defined in the Gosocket administration portal, in the issuer's configuration, per document type: each typeDoc is routed to SUNAT or to the OSE, and the Daily Summary has its own rule. With no rule defined for a type, the destination is SUNAT. xPOS receives these routing rules (routingRules) with the onboarding data: it is not a parameter that travels in each call.

Document types (`typeDoc`)

`typeDoc`	Document	Validation schema
`01`	Electronic Invoice	`UBL-Invoice-2.1.xsd`
`03`	Electronic Sales Receipt (Boleta de Venta)	`UBL-Invoice-2.1.xsd`
`05`	Air Transport Ticket	`UBL-Invoice-2.1.xsd`
`07`	Electronic Credit Note	`UBL-CreditNote-2.1.xsd`
`08`	Electronic Debit Note	`UBL-DebitNote-2.1.xsd`
`09`	Sender's Dispatch Guide (Guía de Remisión Remitente)	`UBL-DespatchAdvice-2.1.xsd`
`14`	Electronic Public Services	`UBL-Invoice-2.1.xsd`
`25`	Attribution document	`UBL-Invoice-2.1.xsd`
`30`	DAE Acquirer	`UBL-Invoice-2.1.xsd`
`31`	Carrier's Dispatch Guide (Guía de Remisión Transportista)	`UBL-DespatchAdvice-2.1.xsd`
`34`	DAE Operator	`UBL-Invoice-2.1.xsd`
`42`	DAE Acquirer	`UBL-Invoice-2.1.xsd`
`56`	SEAE payment voucher / DAE-SEAE	`UBL-Invoice-2.1.xsd`

All types share the same transformation path; what changes per type is the UBL validation schema and the SUNAT service it is sent to (guides 09 and 31 go to the Dispatch Guide service).

Voiding Communication and Daily Summary are internal

The RA (Voiding Communication) and RC (Daily Summary) events are not issued from the POS: xPOS itself builds and sends them. The Daily Summary is documented below.

Input formats (`inputType`)

`inputType`	Supported	Detail
`json`	✓	The receipt's GUF. Full transformation path (root → generic DTE → fiscal UBL).
`xml`	✓	The POS sends the xPOS generic DTE, not SUNAT's UBL: the first transformations are skipped and only the conversion to fiscal UBL runs.
`txt`	✓	The POS plain text, with its own transformation sheet. See Where `txt` and `xdoc` come in.
`xdoc`	✓	xDoc in base64, with its own transformation sheet.

XSLT mapping

Peru's sheets are distributed compiled (.sef format — xPOS does not compile templates in the store) and arrive from the portal with the issuer's configuration:

Sheet	Use
`input_to_dte_pe.sef`	`json` input → generic DTE. With `inputType=xml` this step is skipped.
`dte_to_fiscal_pe.sef`	Generic DTE → SUNAT fiscal UBL. Always runs.
`create_response_pe.sef`	Custom response in `GET /api/v1/status`, when the issuer's output mode is `Personalizada`.
`summary_documents_pe`	Builds the Daily Summary from the day's signed UBLs. It ships packaged in the product, not through the configuration channel: changing the shape of the summary requires an xPOS update.

The txt and xdoc inputs use their own input sheets (other_to_dte and xdoc_to_dte), which arrive through the same configuration channel.

Numbering: series and correlative travel in the document

Peru does not assign folios: the POS puts the series and the correlative in the GUF (<Serie> and <Numero>), and together they form the receipt's identity, F001-00000001.

The receipt number has a single form, SERIES-CORRELATIVE with a hyphen, in the response (docNumber and countryIdentificationCode), in the GET /api/v1/status query and in every dashboard view. The response also carries the series and the correlative separately, in series and number.

🚦 What xPOS returns to the POS

In Peru the HTTP code of the POST /api/v1/process-documents response already says what to do. The stage field and the tax authority code (at the start of error_description) give the detail.

200DeliverAccepted by the tax authority (CDR 0), accepted with observations, or in contingency because there was no network. Print with the QR that comes in the response.

503Retry now, same numberIt is unknown whether it arrived. Resend the same document with the same number: if the tax authority already had it, xPOS recovers the confirmation.

510Fix and retry, same numberThe tax authority received it and did not process it: internal error, credentials, format or packaging. The number was not registered.

400Not issuedWith ET_RESPONSE_STAGE the tax authority rejected it: the number was used, issue with a new folio. With another stage: fix the document.

HTTP	What happened	Stage (`stage`)	What the POS does
200	Accepted (CDR `0`), accepted with observations, or in contingency because there was no network	—	Deliver and print with the response's QR
503	It is unknown whether it arrived: read timeout, cut after sending, HTTP 500 without Fault, 504, Faults `0125`, `0140`, `0307`	`TIMEOUT_ERROR_503`	Resend the same document now with the same number
510	The tax authority received it and did not process it: internal error (`0109`, `013x`, `020x`, `025x`), credentials or configuration (`0101`–`0106`, `0110`–`0113`, `0152`–`0154`, `0400`, HTTP 401/403), format (`1xxx`, `03xx`) or packaging (`0151`, `0155`–`0161`, `1034`)	`COMPLIANCE_ERROR_510`	Fix the cause (or wait a few minutes if it is an internal tax authority error) and resend with the same number: it was not registered
400	The tax authority rejected it: CDR other than `0`, Faults `2xxx`–`3xxx`, `0100`	`ET_RESPONSE_STAGE`	Issue with a new folio: the number was used
400	xPOS could not process it: XSD, data, duplicates	`VALIDATE_XSD_STAGE`, `INVALID_REQUEST`, `VALIDATE_DUPLICITY_STAGE`, …	Fix the document
400	Unexpected error while preparing or sending, for example an unknown destination in the issuer's routing rules	`SEND_BILL_STAGE`	Review the onboarding configuration; escalate to Gosocket

The HTTP status is derived from the stage

The HTTP code is the actual status of the REST response. The stage is still a body field, distinct from the status: the server derives one from the other (TIMEOUT_ERROR_503 → 503, COMPLIANCE_ERROR_510 → 510, any other error → 400). The rule is common to all countries —see Response and error handling—; Peru applies it systematically to every tax authority response.

Peru is not available over WebSocket

The WebSocket channel has no implementation for Peru. Integrate issuance over REST, with POST /api/v1/process-documents.

The error_description always carries the tax authority code first:

- No existe información de receptor de documento...
- Usuario o contraseña incorrectos. ...
- El sistema no puede responder su solicitud... Reenvíe el mismo documento en unos minutos.

Where each case ends up

Case	Processed documents	Erroneous documents	Inbox
Accepted	Yes	No	Status 2
Rejected by the tax authority (400 `ET_RESPONSE_STAGE`)	No	Yes	Status 3
503 or 510	No	Yes, for diagnosis	No: the POS will retry the same number
In contingency	Yes, with `contingencyCode`	No	Status 14

A 503 or 510 in "Erroneous documents" does not block resending: the duplicate validation only looks at documents with a final response.

Response examples

Responses from documents issued in sandbox, sanitized: the RUC and the acquirer's document were replaced by X, and base64 fields are shown truncated.

{
"transactionId": "fe39ba6c-e975-4216-a935-8a7786f85640",
"message": "Operation Successful",
"custom_response": "null",
"errorsDescription": [],
"countryIdentificationCode": "FCON-68",
"timeGeneration": "2026-10-01T13:59:49.486Z",
"output": "PD94bWwgdmVyc2lvbj0iMS4w… (signed XML, base64)",
"input": "eyJEVEUiOnsiRG9jdW1lbnRv… (received GUF, base64)",
"param": "CONSOLIDATE",
"signedXml": "PD94bWwgdmVyc2lvbj0iMS4w… (signed XML, base64)",
"typeDoc": "01",
"number": "68",
"series": "FCON",
"barcodeText": "20XXXXXXXXX|01|FCON|68|18.00|118.00|2026-10-01|6|20XXXXXXXXX|oJ8T+FnfNL/XDJUYWBWR6PrUYv8=",
"barcodeBase64": "iVBORw0KGgo… (QR PNG, base64)",
"valorResumen": "oJ8T+FnfNL/XDJUYWBWR6PrUYv8=",
"docNumber": "FCON-68",
"statusCode": "0",
"statusMessage": "El documento FCON-68 ha sido aceptado",
"applicationResponse": "PD94bWwgdmVyc2lvbj0iMS4w… (CDR, base64)"
}

Notes on the examples:

output and signedXml are the same value: the signed UBL in base64, with the custom data returned.
In contingency, statusCode and applicationResponse do not come: there is no tax authority response yet. statusMessage carries the reason: the network error as reported by the operating system, or "Contingencia manual activa" (manual contingency active).
In the 503, the POS resent the same document with the same number one minute later and it was accepted: the 503 did not consume the number.
0100 is treated as a rejection (400, issue with a new folio) even though the tax authority does not deliver a CDR.

The request is the same as in every country, with country=pe:

POST http://localhost:3200/api/v1/process-documents?env=sbx&operation=consolidate&typeDoc=01&country=pe&inputType=json&origin=20123456789
Content-Type: application/json

{ "DTE": { "Documento": { … } } }

🔁 Resending the same number and duplicates

Recovery when resending after a 503

After a 503 the POS resends the same document with the same number. If the first submission did arrive, the tax authority answers 1033/2109 ("previously registered") or 1032 ("already reported, voided or rejected"). In that case xPOS looks for its previous attempt with that number and queries the confirmation from the tax authority before answering:

Confirmation	Previous attempt in xPOS	Response
Accepted	Yes	200: the XML of the first attempt is returned with its CDR
Accepted	No	400: numbering collision, another receipt uses that number; Gosocket is notified
Rejected	—	400 with that confirmation
Does not exist	—	510: tax authority inconsistency, escalated to Gosocket
The query fails	—	503: retry in a few minutes
Direct SUNAT destination (no confirmation query)	—	400: check the SUNAT portal before reissuing

The numbering collision appears, for example, when reusing a number already issued from a previous onboarding of the same RUC: the tax authority has it registered and xPOS has no previous attempt.

{
"message": "Operation Error",
"error_description": "1033 - Descripción: El comprobante fue registrado previamente con otros datos. La entidad tributaria ya tiene registrado otro comprobante con el número FCON-67 (1033) y xPOS no tiene un intento previo de este folio: colisión de numeración. No se regularizó; emita un folio nuevo y revise la asignación de correlativos.",
"transactionId": "b975be62-dcc7-4c4b-b7a9-6655ea9ebc0e",
"docNumber": "FCON-67",
"stage": "ET_RESPONSE_STAGE",
"applicationResponse": "PHM6RW52ZWxvcGUgeG1sbnM6… (tax authority Fault, base64)",
"input": "eyJEVEUiOnsiRG9jdW1lbnRv… (received GUF, base64)",
"output": "PD94bWwgdmVyc2lvbj0iMS4w… (signed XML, base64)",
"contingencyCode": "null"
}

Duplicates with the stored response

Before signing, xPOS checks whether the same number from the same issuer already has a final response. If it does, it does not send it again: it answers 400 VALIDATE_DUPLICITY_STAGE with what was stored inside the error.

Already accepted: carries the stored signed XML (output) and CDR (applicationResponse).
In contingency: states that it is already in contingency, with its contingencyCode.
Rejected: carries the stored rejection and the instruction to issue with a new folio.
Regularized paper receipt: reported as a duplicate.

A previous 503 or 510 does not count as a final response, so resending that number goes through normally.

{
"message": "Operation Error",
"error_description": "Documento duplicado: el número FCON-68 ya fue aceptado por la entidad tributaria el 2026-10-01T13:59:49.486Z. Se devuelve el XML y la constancia registrados; no se vuelve a enviar.",
"transactionId": "8669979c-722e-4a1d-b87f-48a56cff7dec",
"docNumber": "FCON-68",
"stage": "VALIDATE_DUPLICITY_STAGE",
"applicationResponse": "PD94bWwgdmVyc2lvbj0iMS4w… (stored CDR, base64)",
"input": "eyJEVEUiOnsiRG9jdW1lbnRv… (received GUF, base64)",
"output": "PD94bWwgdmVyc2lvbj0iMS4w… (stored signed XML, base64)",
"contingencyCode": "null"
}

🕒 Contingency

In Peru only what never reached the tax authority enters the contingency queue. A formal online response from the tax authority —acceptance, rejection or error— is final and returns to the POS with its HTTP code.

What enters the queue: network down before connecting (DNS, connection refused, no route), HTTP 502/503 from the load balancer without a SOAP response, manual contingency active, and receipts or receipt notes to which the tax authority answers 1079.

What the POS receives: 200 with message = "Operation Successful en contingencia", the signed XML, the docNumber with a hyphen and contingencyCode 1. Manual contingency emulates an internet outage, so it also answers 1: for the POS it is the same as losing the network. See the 200 — In contingency example in Response examples. The copy sent to the Inbox carries the reason ContingencyTypeCode 01, issuer internet outage (see Contingency reasons).

Route by document:

Document	Route	Cadence
Receipts (`03`) and receipt notes (series `BC`/`BD`)	Daily Summary (see below)	Grouped for 60 s after the last receipt, capped at 5 min; at least 5 min between batches
Invoices (`01`) and invoice notes (series `FC`/`FD`)	Automatic resending, one by one	Every 2 min for the first half hour, then every 10 min; before a second resend it queries the confirmation

The note's series defines its route

A credit or debit note whose series does not match the document it modifies —an invoice note with series B, or a receipt note with series F— is rejected before signing with INVALID_REQUEST.

What automatic resending does with each response:

Accepted or rejected: closes the document with that verdict and reports the final status to the Inbox.
Internal tax authority error, credentials or packaging: the document stays in the queue and is retried. Credential and packaging errors also notify Gosocket support every 6 hours.
Uncertain response: resolved by querying the confirmation.

A document already delivered to the POS is never lost because of a transient tax authority response.

Deadlines

Deadlines are counted in calendar days from the day after issuance, in Lima time, and expire at midnight Lima time.

Document	Window	Expires (issued on day E)
Invoices and invoice notes	3 calendar days	At the start of day E+4
Daily Summary (batch of receipts from date E)	7 calendar days	At the start of day E+8

On expiry there is a single closing submission and the tax authority decides. If it does not accept it, the document is Rejected for deadline: with the tax authority's deadline code (2108, 2329, 2600, 2950) or, if there was no formal response, with the xPOS code XPOS_PLAZO_VENCIDO. It goes to the Inbox with status 3 and the note "PLAZO", and appears in "Erroneous documents". There is no "expired" status.

📋 Daily Summary of receipts (boletas)

Sales receipts (boletas) and receipt notes that enter the contingency queue are declared to SUNAT grouped in a Daily Summary (RC batch), with its own asynchronous cycle: the batch is sent, the tax authority returns a ticket, and with that ticket xPOS later queries the confirmation (CDR). xPOS builds and sends the batches automatically, with no POS or store intervention.

A batch covers a single issuance date. Receipts issued in contingency are declared in the batch of their issuance date: a store that spent three days in contingency generates three batches.
Identifier RC-YYYYMMDD-NNNNN, with a daily correlative per issuer: on devices with several issuers each one keeps its own batch series. The correlative is only consumed when the batch passed the XSD: a network outage does not consume correlatives.
The verdict applies to the whole batch: if accepted, each receipt is accepted (status 2 in the Inbox); if rejected, each receipt is rejected (status 3) with the reason note.
If the submission fails due to the network or a transient tax authority error, the batch stays signed and is retried with the same identifier until it expires. With the ticket in hand, xPOS queries the CDR every 2 minutes.
A SUNAT Fault when sending the batch is a verdict, not an outage: if it is a rejection, the batch is Rejected with the Fault visible.
Fault that leaves nothing declared: with 2223 (file already submitted) or 0126/0127 (foreign or nonexistent ticket), the batch is rejected and its receipts return to the queue for a new batch. No action required.
Expiry: the batch expires 7 calendar days after the issuance date it declares. See Deadlines.
A receipt already declared in an accepted batch is not declared again.

Real case: 2223 in the first batch of the day

When a new onboarding is installed on a device that was already issuing with that RUC, the day's correlative goes back to 00001, which had already been submitted to the tax authority. Batch RC-…-00001 is rejected with 2223, xPOS reopens its receipts and the next batch, RC-…-00002, is accepted. No action required.

Batches, their expiry and their response can be checked in the dashboard Summaries view.

📊 Contingencies and Summaries in the dashboard

In the local dashboard, Peru shows its contingency model in the document views and adds the Summaries menu. The Status at the tax authority column uses the common statuses plus Queued for submission, specific to Peru: the receipt awaits its submission or its response from the queue.

Contingencies and Failed documents

Contingencies. One row per receipt that went through the queue, with the Status at the tax authority column and the Summary column, which indicates in which Daily Summary batch each receipt was declared. Example, with illustrative data:

Type	Document No.	Date	Code	Status at the tax authority	Summary
03	B001-00000125	28/09/2026 15:02:11	1	Queued for submission	–
03	B001-00000124	28/09/2026 14:58:40	1	In process	RC-20260928-00003
03	B001-00000120	28/09/2026 12:10:05	1	Accepted	RC-20260928-00002
01	F001-00000452	28/09/2026 11:47:30	1	Conditionally accepted	–
01	F001-00000431	24/09/2026 09:15:22	1	Rejected	–

Failed documents. Shows tax authority rejections, 503 and 510 errors —for diagnosis: they do not block resending the same number— and deadline closures, with the receipt number.

Summaries view

Available since version 2.7.1

Summaries menu, visible only on Peru installations. It has the same filters as the other views.

One row per Daily Summary batch:

Column	Content
Summary	Batch identifier, `RC-YYYYMMDD-NNNNN`.
Generated	When the batch was built.
Sent	When it was sent to the tax authority; empty while still pending.
Expires	The batch's expiry date. Shown in red if an open batch has already expired.
Status at the tax authority	Created; Signed, pending submission; Sent, awaiting CDR; Accepted or Rejected.
Ticket	The ticket returned by the tax authority.
Receipts	The receipts declared in the batch.

Row actions: View Summary XML and View tax authority response.

Example, with illustrative data:

Summary	Generated	Sent	Expires	Status at the tax authority	Ticket	Receipts
RC-20260928-00003	28/09/2026 15:05:00	28/09/2026 15:05:02	06/10/2026 00:00	Sent, awaiting CDR	1759090302551	4
RC-20260928-00002	28/09/2026 12:15:00	28/09/2026 12:15:03	06/10/2026 00:00	Accepted	1759079703127	12
RC-20260927-00004	27/09/2026 23:40:00	–	05/10/2026 00:00	Signed, pending submission	–	2
RC-20260926-00001	26/09/2026 10:00:00	26/09/2026 10:00:02	04/10/2026 00:00	Rejected	1758898802004	3

🧾 Regularized paper receipt

If the store sold with a paper receipt book (physical receipt), the POS regularizes it by sending it with the custom field ContingencyTypeCode, with a value from 02 to 07 (see Contingency reasons), just as in Costa Rica and the Dominican Republic. It accepts invoices, receipts and notes.

<Personalizados>
  <DocPersonalizado dteID="">
    <campoString name="ContingencyTypeCode">02</campoString>
  </DocPersonalizado>
</Personalizados>

It does not go to the tax authority or the queue: it is validated, signed and sent to the Inbox.
The response is 200 with contingencyCode 3.
A resend of the same number answers as a duplicate.

Contingency reasons (`ContingencyTypeCode`)

SUNAT's reason catalog. 01 is the only automatic one: xPOS assigns it to every document that enters the contingency queue, including manual contingency, which emulates an internet outage. 02 to 07 are manual: the POS sends them in the ContingencyTypeCode custom field when regularizing a paper receipt.

`ContingencyTypeCode`	Reason	Type
`01`	Issuer internet outage	Automatic
`02`	Power supply failures	Manual
`03`	Natural disasters	Manual
`04`	Theft	Manual
`05`	Invoicing system failures	Manual
`06`	Itinerant sale	Manual
`07`	Other	Manual

Do not confuse it with the contingencyCode of the response to the POS, which in Peru is 1 (automatic) or 3 (manual: regularized paper receipt).

🔳 Printed representation QR

xPOS generates the SUNAT QR (Annex B) and returns it in the response, ready to print:

Field	Content
`barcodeText`	The QR string: `RUC \| type \| series \| number \| IGV \| total \| date \| acquirer doc type \| acquirer doc number \| summary value`
`barcodeBase64`	The QR as a PNG image in base64
`valorResumen`	The hash of the signed XML, the same value that closes `barcodeText`

Example barcodeText (sanitized RUC):

20XXXXXXXXX|01|FCON|68|18.00|118.00|2026-10-01|6|20XXXXXXXXX|oJ8T+FnfNL/XDJUYWBWR6PrUYv8=

If QR generation fails, the sale goes on.

Dispatch guides (09, 31): SUNAT delivers the QR inside the CDR. xPOS returns it in barcodeText and in gre.qrUrl; gre.transportEnabled is true only when the guide was accepted and the link is present.

Peru-specific response fields

Peru returns the core + partial tax echo (statusCode and statusMessage, without statusDescription) + applicationResponse + timeGeneration + QR + its own fields (series, valorResumen and, in guides, gre).

Field	Status	Notes
`statusCode` / `statusMessage`	✓	Read from the CDR. `statusCode: "0"` = receipt accepted. In contingency `statusCode` does not come, and `statusMessage` carries the reason for the contingency.
`statusDescription`	–	Not emitted in Peru.
`applicationResponse`	✓	The CDR in base64. In a rejection it carries the tax authority's CDR or Fault; in a duplicate, the stored CDR. In contingency it does not come.
`countryIdentificationCode`	✓	The receipt's series-correlative, equal to `docNumber`. Peru has no additional identifier assigned by the tax authority.
`series`	✓	The receipt's series (`F001`). Peru's own field.
`timeGeneration`	✓	ISO 8601.
`timeValidation`	–	Not emitted in Peru.
`barcodeText` / `barcodeBase64`	✓	The SUNAT QR: the string and the PNG image in base64.
`valorResumen`	✓	The hash of the signed XML. Peru's own field.
`gre.qrUrl` / `gre.transportEnabled`	✓	Only in dispatch guides (`09`, `31`).
`contingencyCode`	✓	`1` = automatic contingency (no network; also the dashboard's manual contingency, which emulates an internet outage); `3` = manual contingency (regularized paper receipt). The reason goes in `ContingencyTypeCode`. In errors it arrives as the string `"null"`.
`custom_response`	–	Arrives as the string `"null"`: Peru's Custom output operates in `GET /api/v1/status`, not in issuance.
`partnerNumber`	–	Does not apply in Peru.

Tax authority errors, readable

SUNAT's and the OSE's services respond in SOAP: a failure on the tax authority's side does not arrive as an HTTP error but as a SOAP Fault inside a technically successful response. xPOS extracts the Fault's code and description, so that:

A receipt rejected by the tax authority is not marked as successfully sent.
The reason reaches the POS (error_description, with the code first), the dashboard and the portal in readable form.
The response's HTTP code classifies the case: 503, 510 or 400.

The stage catalog and the classification of SUNAT/OSE codes are in Error codes · Peru.

Particular notes

Publishes in Inbox-Gosocket (or through the System Integrator channel when the organization has it enabled).
Re-retrieval via GET /api/v1/status with transactionId or with docNumber + typeDoc. For Peru, docNumber is the series-correlative with a hyphen (F001-00000001). With more than one issuer installed, the query by number also requires origin.
The issuer is validated against origin: if the RUC of the issuer inside the document does not match the request's origin, issuance fails at VALIDATE_ISSUER_STAGE.
Voiding: POST /api/v1/cancelation-event does not apply to Peru. The voiding of a Peruvian receipt is declared to SUNAT through a Voiding Communication, which travels through the same asynchronous ticket cycle as the Daily Summary and is built by the platform itself — its enablement is in preparation; today there is no parameter with which the POS can request a voiding. Coordinate voiding cases with your Gosocket contact.
Client custom data: travels in the <Personalizados> node, which contains a <DocPersonalizado> with the campoString fields. Since version 2.7.1, the signed XML the POS receives (output / signedXml) and the one shown by "View document" in the dashboard carry the custom data back.

<Personalizados>
  <DocPersonalizado dteID="">
    <campoString name="Mail1">…</campoString>
  </DocPersonalizado>
</Personalizados>