home

Indirect Tax

Sovos Docs

Peru

Enabling support for Peru requires SUNAT registration, Clave SOL credentials, a valid RUC and residency, a registered sender email, and a digital certificate.

Prerequisites

Document types

Sovos supports submitting the following document types to SUNAT: Nota de Crédito, Nota de Débito, Factura Electrónica, boleta, Comprobante de Retención CRE, Comprobante de Percepción CPE, Guía de Remisión Electrónica, and Documento Autorizado Electrónico 14.

Document types for canceling an invoice:

Baja
You can cancel an invoice by creating a Baja within seven days, as long as it has not been delivered to the buyer and it has received a CDR (Constancia de Recepción) from SUNAT. The process of using a Baja to cancel an invoice is simple because you don't need to submit additional declarations to SUNAT. However, if the invoice has already been issued to the buyer, you must issue a Nota de Crédito instead.
Nota de CrƩdito
Used to cancel invoices throughout the fiscal year, in case of operational errors or problems in the RUC. You can cancel an invoice with this document type when the invoice has already been delivered to the buyer. After canceling, the PDF of the issued nota de crƩdito must be sent to the buyer and also declared by both the receiver and the sender.
Note:

For more details on cancellation, see the SUNAT web page.

Available products

Note: This country has no defined products.

Duplicate invoices

The supplier is responsible for handling duplicate invoices. Because Sovos assigns a unique invoice number to each received invoice, we do not consider any invoice as a duplicate. Therefore, if the supplier resends an invoice, considers it a new invoice and assigns it a unique number. To avoid duplication, the supplier must implement a mechanism to prevent sending duplicate invoices.

Error handling

When handling errors, the client application must follow the Indirect Tax API's error handling principles, as specified in the error handling documentation.

In general, all error codes in the 400 range are client errors, which you need to analyze. After fixing the error, you can resend the request. Error codes 408 and 429 are exceptions: In these cases, you should wait at least 60 seconds before retrying. Error codes in the 500 range are server errors. In that case, resend the request according to the instructions given on the error handling documentation, which also includes a full list of error codes Indirect Tax API can return.

Errors coming from the tax authority are shown in the application response. This means that if the tax authority rejects the request, SCIResponseCode is set to "RE" and any error codes will be located in the SCIGovtStatusCode element.

Note:

You need to take action after receiving an error code and a message from the tax authority.

Issue invoice

Issue an invoice in Peru is based on the Default business process, which follows this order: Mapping, Signing, Transmission, and Distribution. The following diagram provides a detailed overview:

Peru outbound flow

Step 1: Supplier creates the Standard Business Document

Every transactional document sent to Sovos must be part of a Standard Business Document (SBD). This document includes a Standard Business Document Header (SBDH) and a Sovos Document node, which in turn includes a Sovos Canonical Invoice (SCI). To create the SBD, follow the detailed instructions in the SBDH, Sovos Document, and SCI pages.

Here are some key elements that should be included in the SBD:

Use the following values in the SBDH for invoice documents that use the SCI format:

NodeRequiredAttributesValue
StandardBusinessDocumentHeader.Sender.IdentifierYesAuthority="PE"Supplier's RUC
StandardBusinessDocumentHeader.Receiver.IdentifierYesAuthority="PE"
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersionYes2.1
StandardBusinessDocumentHeader.DocumentIdentification.TypeYesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Country

Child node Identifier: PE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: ProcessType

Child node Identifier: Outbound

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: CompanyCode

Child node Identifier : Supplier's RUC

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: SenderDocumentId

Child node Identifier: A unique document ID. We recommend the ERP document ID.

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: SenderSystemId

Child node Identifier: The system ID configured in the backend. This parameter is used to determine which notifications are returned to the client and what attachments they include. If SenderSystemId is not configured on the client side, it will use the default value of "DefaultSystemERP". For more information, see this topic.

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier : UBLInvoice

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: SCI-TO-LEGAL_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)No

Child node Type: BusinessCategory

Child node Identifier: Child node Identifier: BusinessToBusiness or BusinessToConsumer. The default mode is BusinessToBusiness when this node is omitted, so if the transaction is business to consumer, this must be explicitly specified.

StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceNameYesDefault
SovosDocument.SovosCanonicalInvoice.InvoiceYesSCI

In case you want to send a nota de crƩdito, make these changes in the SBDH:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.Standard Yes urn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.Type YesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier : UBLCreditNote

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier : SCI-TO-LEGAL_CREDIT_NOTE

In case you want to send a nota de dƩbito, make these changes in the SBDH:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.Standard Yesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.Type YesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier : UBLDebitNote

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier : SCI-TO-LEGAL_DEBIT_NOTE

In case you want to send a guia de despacho document, make these changes in the SBDH:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.Standard Yesurn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2
StandardBusinessDocumentHeader.DocumentIdentification.Type YesDespatchAdvice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier : UBLDispatchAdvice

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier : SCI-TO-LEGAL_DESPATCHADVICE

In case you want to send a comprobante de percepción document, make these changes in the SBDH:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.Standard Yesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.Type YesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier : Perception

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier : SCI-TO-LEGAL_PERCEPTION

In case you want to send a comprobante de retención (CRE) document, make these changes in the SBDH:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.Standard Yesurn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.Type YesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier : Retention

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier : SCI-TO-LEGAL_WITHHOLDING

Note:

Include all the mandatory nodes, as specified in the SBDH schema. If the information cannot be provided, and the respective mandatory node has not been mentioned on the current page, for example the receiver.identifier, the node can be left empty but must still be included in the SBDH.

SBD sample
Below is a sample of the SBD. In addition, there's a full sample of the SBD on the Postman Samples page.
<?xml version="1.0" encoding="UTF-8"?>
<sbd:StandardBusinessDocument xmlns="http://uri.etsi.org/01903/v1.4.1#" xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="PE">77388600-8</sbd:Identifier>
			<sbd:ContactInformation>
				<sbd:Contact>Sovos Support</sbd:Contact>
				<sbd:EmailAddress>support@sovos.com</sbd:EmailAddress>
				<sbd:FaxNumber>+1-212-555-1213</sbd:FaxNumber>
				<sbd:TelephoneNumber>+1-212-555-2122</sbd:TelephoneNumber>
				<sbd:ContactTypeIdentifier>Support</sbd:ContactTypeIdentifier>
			</sbd:ContactInformation>
		</sbd:Sender>
		<sbd:Receiver>
			<sbd:Identifier Authority="PE">98765432-1</sbd:Identifier>
			<sbd:ContactInformation>
			    <sbd:Contact/>
			    <sbd:EmailAddress/>
			    <sbd:FaxNumber/>
			    <sbd:TelephoneNumber/>
			    <sbd:ContactTypeIdentifier/>
			</sbd:ContactInformation>
		</sbd:Receiver>
		<sbd:DocumentIdentification>
			<sbd:Standard>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2</sbd:Standard>
			<sbd:TypeVersion>2.1</sbd:TypeVersion>
			<sbd:InstanceIdentifier/>
			<sbd:Type>Invoice</sbd:Type>
			<sbd:MultipleType>false</sbd:MultipleType>
			<sbd:CreationDateAndTime>2020-06-02T00:00:00Z</sbd:CreationDateAndTime>
		</sbd:DocumentIdentification>
		<sbd:BusinessScope>
			<sbd:Scope>
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>PE</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Mapping.TransformDocument</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>SCI-TO-LEGAL_INVOICE</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Mapping.OutputSchema</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>UBLInvoice</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>CompanyCode</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>77388600-8</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderDocumentId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>F00001795T52</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderSystemId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>UAT101</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>ProcessType</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>Outbound</sbd:Identifier>
			</sbd:Scope>
            <sbd:Scope>
                <sbd:Type>BusinessProcess</sbd:Type>
				<sbd:InstanceIdentifier/>
                <sbd:BusinessService>
                    <sbd:BusinessServiceName>Default</sbd:BusinessServiceName>
                </sbd:BusinessService>
            </sbd:Scope>
			<sbd:Scope>
				<sbd:Type>BusinessCategory</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>BusinessToBusiness</sbd:Identifier>
			</sbd:Scope>
		</sbd:BusinessScope>
	</sbd:StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<sci:SovosCanonicalInvoice>
			<inv:Invoice>
				*UBL Nodes*
			</inv:Invoice>
		</sci:SovosCanonicalInvoice>
	</svs:SovosDocument>
</sbd:StandardBusinessDocument>

Step 2: Supplier sends the SBD to Sovos

The supplier sends a POST request to the /documents endpoint.

The request must include the following request body parameters:

NameTypeRequiredDescription
datastringYesThe SBD encoded in Base64, as created in step 1.
dataEncodingstringYesEnter "base64".
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '{
	"data": "PD9...d4=",
	"dataEncoding" : "base64"
}'
Response sample
{
    "timestamp": 1620128574735,
    "status": 202,
    "success": true,
    "message": "Document Received",
    "data": {
        "documentId": "Q0x8NzYxNTcyMjAtMnwxNjIwMTI4NTc0NjQxfDYxOTYzNDIyOQ=="
    }
}

Step 3: Sovos maps the SCI into XML

Upon receiving the SCI, Sovos maps the file into the required XML format.

Step 4: Sovos performs the schema validation

Sovos performs a schema validation to determine whether the XML file conforms to the expected structure by validating it against the official schema.

Step 5: Sovos signs the XML

Sovos signs the XML with the configured certificate.

Step 6: Storing

Sovos stores the signed CPE XML.

Step 7: Sovos transmits the XML

Sovos transmits the signed CPE XML file to OSE for clearance.

Step 8: OSE processes and stores the XML

OSE validates the correct issuance of the XML and also saves a copy of the validation along with the XML.

After authentications, the OSE sends a CDR to Sovos and the CDR, along with the XML, to the tax authority.

The CDR or Receipt Certificate holds details for the status of the electronic document. An electronic document can have the following statues:

Accepted
The electronic document meets the standards and validation criteria.
Accepted with observation
The electronic document complies with the established validations but you might need to edit some information.
Note:

A CDR is not issued if there are errors resulting from SUNAT rejecting a document.

Step 9: Sovos generates the PDF

Sovos generates a PDF file that includes the content of the CPE XML based on the configured PDF template.

Step 10: Sovos distributes the PDF and the XML

As explained in step 11, the supplier can retrieve the CPE XML and the PDF through a GET API request. But Sovos can also distribute the PDF and the CPE XML by email:

Note:

The delivery method must be preconfigured. Otherwise, this step will be skipped.

Step 11: Supplier retrieves the application responses

As a response to the initial sending of the document, the client receives a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the supplier must retrieve the application responses that become available during the transaction, which provide status information and a URL to access the cleared CPE XML and the PDF after they're available during the process.

To complete a transaction, the supplier must retrieve application responses until the SCIResponseCode in the response has the value of either "AP" or "RE", which indicates that the transaction is finished.

The supplier can use the following Indirect Tax API endpoints to retrieve application responses:

  • GET /notifications/PE

  • GET /documents/PE/{documentId}/notifications

GET /notifications/PE
The supplier can send a GET request to the /notifications/PE endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNo Include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.
pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

To specify the number of results for the returned page, enter a value between 1 and 100.

Note: If the attachment file is configured to return the binary content instead of a link, use only values between 1 and 10.

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/PE?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "timestamp": 1633690045950,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 2,
            "totalPages": 799226,
            "totalEntries": 1598451
        },
        "notifications": [
            {
                "createdDate": "1604415975006",
                "metadata": {
                    "documentId": "Q0x8NzYxNTcyMjAtMnwxNjA0NDEzNzA4NDQxfDgzOTQxMjU5MA==",
                    "erpDocumentId": "3733770",
                    "taxId": "761572202",
                    "sciCloudStatusCode": 200,
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": ""
                },
                "appPrefix": "PPL",
                "notificationId": "915015",
                "content": "PEF...c2U+"
            },
            {
                "createdDate": "1604415856547",
                "metadata": {
                    "documentId": "Q0x8NzYxNTcyMjAtMnwxNjA0NDEzNzA4NDQxfDgzOTQxMjU5MA==",
                    "erpDocumentId": "3733770",
                    "taxId": "761572202",
                    "sciCloudStatusCode": 101,
                    "sciResponseCode": "IP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": ""
                },
                "appPrefix": "PPL",
                "notificationId": "915016",
                "content": "PEF...ZT4="
            }
        ]
    }
}
GET /documents/PE/{documentId}/notifications
The supplier can send a GET request to the /documents/PE/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameters:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 2
includeAcknowledgedbooleanNoQueryfalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/PE/{documentId}/notifications?includeAcknowledged=true' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "timestamp": 1633690226316,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 2,
            "totalPages": 2,
            "totalEntries": 4
        },
        "notifications": [
            {
                "createdDate": "1620128575181",
                "metadata": {
                    "documentId": "Q0x8NzYxNTcyMjAtMnwxNjIwMTI4NTc0NjQxfDYxOTYzNDIyOQ==",
                    "erpDocumentId": "1100000111",
                    "taxId": "761572202",
                    "sciCloudStatusCode": 101,
                    "sciResponseCode": "IP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "",
                    "sciGovtStatusMessage": ""
                },
                "appPrefix": "PPL",
                "notificationId": "3066477",
                "content": "PEF...c2U+"
            },
            {
                "createdDate": "1620237743251",
                "metadata": {
                    "documentId": "Q0x8NzYxNTcyMjAtMnwxNjIwMTI4NTc0NjQxfDYxOTYzNDIyOQ==",
                    "erpDocumentId": "1100000111",
                    "taxId": "761572202",
                    "sciCloudStatusCode": 202,
                    "sciResponseCode": "RE",
                    "sciStatusAction": "NIN",
                    "sciGovtStatusCode": "",
                    "sciGovtStatusMessage": ""
                },
                "appPrefix": "PPL",
                "notificationId": "3066761",
                "content": "PEF...ZT4="
            }
        ]
    }
}

Step 12: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/PE endpoint.

To make this request, set the following request body parameters:

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in one Indirect Tax API call by including them in a single request.
Request sample
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/PE' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-fd3e-4dcf-aea3-a73d73e0de76"
    }
]'
Response sample
{
    "timestamp": 1601673284,
    "status": 200,
    "success": true,
    "message": "Notifications acknowledged successfully."
}

Step 13: Supplier sends the XML and the PDF to the Buyer

As the final step, the supplier should send the CPE XML and optionally the PDF to the buyer via an agreed-upon channel.

Note:

This process is outside the scope of Sovos