home

Indirect Tax

Working with SovosIndirect TaxTax and Regulatory ReportingTrust ServicesSovos Glossary
Working with SovosIndirect TaxTax and Regulatory ReportingTrust ServicesSovos Glossary

Sovos Docs

Show Contents

Show Page Sections

Indirect Tax

Country Setup Guides

Mexico

Enabling support for Mexico involves confirming prerequisites and product IDs, registering with the Servicio de Administración Tributaria (SAT) tax authority, and setting up credentials.

Prerequisites

Addenda

An optional non-regulated element at the end of the Comprobante Fiscal Digital por Internet (CFDI). Its content is commonly used for exchanging any auxiliary information as agreed upon between the supplier and the buyer, such as additional business information about the business transaction or information to be used in the printable CFDI representation. The addenda element is not covered by the supplier's digital signature over the CFDI.

There are several addenda XSDs defined by trading partners or certain industry sectors, and companies can even use a different addenda for each trading partner. Most ERP systems can generate the information that is needed for these addenda. However, there can only be one addenda node per CFDI according to the CFDI schema.

Note: Anexo 20 differs from the official CFDI schema in how it handles addenda. While Anexo 20 accepts either XML or plain-text content in the addenda, the official CFDI schema accepts only well-defined XML. To ensure your Proveedor de Certificación de CFDI (PCCFDI)accepts the invoice, either:

  • Define your addendum according to an XML schema.

  • Remove the addenda before clearance and reinsert it afterward.

Cadena original

A string of characters separated by the “|” (pipe) character. The original string is created by concatenating selected CFDI data elements and determines the CFDI’s uniqueness.

This original string is also used as the unique input to calculate the supplier's CFDI sello (digital signature).

Note:

The CFDI specifications do not rely on the W3C Digital Signature standard to ensure the integrity and authenticity of the digital signature included in the CFDI.

The original string includes a subset of data elements from the CFDI, such as:

  • Supplier and buyer RFCs

  • CFDI type

  • Date and time

  • Total amount

  • Currency

  • ZIP code (numbers only)

  • VAT

  • Series and Folio attributes, if present

  • Elements from supplements, if available

Two different CFDIs that differ in XML elements and are not in the original string might end up having the same original string and the same signature. Such CFDIs would be duplicates from a fiscal standpoint.

Note:

To avoid this collision, ensure that the CFDIs differ in at least one of the elements that are contained in the original string, such as date, series, or folio.

Detailed rules for building the original string are specified in the Anexo 20 document. The official stylesheet for extracting the original string is also available as part of the CFDI Technical Specifications document.

CFDI cancellation

If the CFDI has errors, the Mexican supplier must cancel it, because they can't issue an amendment. To cancel a CFDI, they must use a PCCFDI, which submits the cancellation to the SAT. Suppliers can also cancel the CFDI manually through the SAT portal. They must provide the reason for the cancellation and, in some scenarios, identify the replacement CFDI.

In certain circumstances, the supplier must obtain explicit approval from the buyer before cancellation. This means that the cancellation process is not authorized until the buyer approves it or 72 business hours have passed since the cancellation was issued — at which point, the approval becomes implicit. The buyer's acceptance or rejection is processed through the Buzón Tributario .

CFDI content and catalogs

Besides the mandatory elements of the CFDI required by the schema, some elements are required depending on the supported commercial transaction. It's the taxpayer's responsibility to investigate the fiscal obligations in this respect.

Content values must comply with additional rules specified in the CFDI technical specification catalogs. For example, you can only use Mexican postal index and country codes that appear in the corresponding catalog.

The catalog rules also require rounding some numeric values to a certain number of decimals. The catalogs are available on the SAT website.

CFDI printable representation

There are specific rules on how to generate a printable (human-readable) representation of an XML CFDI. The printable version of the CFDI is optional for the supplier, unless the buyer specifically requires it. Typically, a printable version of the CFDI is in PDF format, but other formats may be used.

The XML CFDI and the printable representation may be transmitted through the same channel as the invoice or through different channels.

You can find the requirements for content shown in the printable representation of a CFDI in the Resolución Miscelánea Fiscal (RMF) document under the rule "Requisitos de las representaciones impresas del CFDI" (as of 2026, this is the rule 2.7.1.7). To find the technical specifications for the QR Code in the Anexo 20 document, go to the section "Especificación técnica del código de barras bidimensional a incorporar en la representación impresa".

CFDI types

The CFDI schema supports different types of fiscal documents. To specify the document type, you must set the value of the TipoDeComprobante CFDI attribute using one capital letter, as follows:

I (Ingreso)
For an invoice or debit note
E (Egreso)
For a credit note
T (Traslado)
For a bill of lading
N (Nomina)
For a payslip
P (Pago)
For a payment
Note:

The clearance process is the same, regardless of the CFDI type.

CFDI validation

Buyers can only claim tax deductions on CFDIs that contain the supplier's signature — a valid Timbre Fiscal Digital (Digital Tax Stamp) supplement. The PCCFDI adds the the SAT digital signature, the fiscal folio UUID, and the certification date to this supplement.

Important:

Using fraudulent documentation to support accounting records might result in administrative sanctions. Buyers must validate received CFDIs to ensure compliance with inbound e-invoicing processes in Mexico.

Supplements

CFDIs document transactions across different activities and sectors. In some cases, the core CFDI requires a complemento (supplement) to provide additional information required by regulation. A supplement is an additional XML complex element within the CFDI.

Supplements are regulated separately from the core CFDI. Each supplement has its own XSD schema, which is independent of the core CFDI schema. The PCCFDI validates supplement content against the required validations and catalogs. During the signing process, the resulting digital signature also protects any included supplements.

Some supplements exist for years without any changes. New supplements and new supplement versions are released occasionally. This can create situations where a new version may coexist with the old one until there is a legal requirement to use the new version and discard the old one. The supplier must always use the legally required version of each supplement.

The complete list of all regulated supplements is available in the SAT’s supplements web page. Commonly used supplements:

Complemento para Recepción de Pagos
Used by suppliers to report when they receive payment for a transaction that was previously documented using a primary CFDI. This supplement's technical specifications are on this SAT web page, which lists the schema, the guidelines, and the catalog.
Complemento para Comercio Exterior
Used by suppliers who need to document export transactions. This supplement's technical specifications are on this SAT web page, which lists the schema, the guidelines, and the catalog. Its catalog includes the country codes, the currency codes, and the number of decimals to be used for the different currencies.

CFDI certification

Timbrado (stamping) or Certificación del CFDI (CFDI Certification) is a required step in the validation and clearance of a CFDI.

When the SAT or an authorized PCCFDI receives a signed CFDI, they validate the XML schema and content, including the supplier's signature. After that, they clear the CFDI by generating the timbre (proof of clearance) supplement. This supplement contains:

  • The SAT signature

  • A unique folio fiscal (invoice number) tagged as a Universally Unique Identifier (UUID)

  • The date

  • Other complementary data

Note:

There is a one-to-one correspondence between the UUID and the Cadena Original (original string).

Suppliers must submit the CFDI to the PCCFDI for clearance and the PCCFDI must certify the CFDI within the next 72 hours. Given Mexico's four distinct time zones, suppliers must specify the applicable time zone to avoid rejections due to timing. After extracting the LugarExpedicion value — the postal index where the CFDI is issued — to locate the time zone for that postal index’s location, the supplier must assign this value to the Fecha (date) attribute in the CFDI.

The PCCFDI must report all certified CFDIs to the SAT in less than two hours.

Available products

  • mx_documento_1_2.0

  • mx_comprobante__4.0

  • mx_comprobante__3.3

  • mx_temp__1.0

  • mx_demo_1_3.3

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.

For additional help on error handling, see this government documentation, which includes all the error codes and messages that the tax authority can return.

Duplicate invoices

You are responsible for avoiding or managing the process of sending duplicate invoices. When Sovos receives a duplicate Mexican invoice, we treat it as a unique invoice, so it goes through the same invoice issuing process. When the invoice reaches the PCCFDI, it responds with the exact same response as when the original transaction was sent, so it does not indicate that the transaction is a duplicate. This means that you will get and can retrieve the same five application responses.

Configure signing credentials for Mexico

  1. Send a POST request to the endpoint URL:
    POST https://api-test.sovos.com/v2/configurations/organizations/{orgId}/settings
  2. Include the following headers in your request:

    • Content-Type: application/json

    • Authorization: Bearer {accessToken}

    • x-correlationId: {uniqueValue}

  3. Include the following parameters inside the JSON payload in the request body.
    NameTypeRequiredDescription
    contextstringYesUse "signing"
    configurationsarray of objectsYes
    namestringYesUse "credentials"
    valueobjectYes
    certificateFileDatastringYesCertificate .cer file encoded in Base64
    certificateFileKeystringYesCertificate .key file encoded in Base64
    passwordstringYesCertificate password
    extensionstringYesUse ".cer"
    extensionKeystringYesUse ".key"
    scopeobjectYes
    categorystringYesUse "MX_INV"
    productIdstringYesUse "mx_comprobante__4.0"
    orgIdstringYesThe organization ID obtained from the Sovos Professional Services team
    taxIdstringYesThe tax ID of the company for which the credentials are being configured

Upon successful creation, the API will return a JSON object containing the uploaded credentials and their assigned SETTING-ID.

Samples for uploading signing credentials for Mexico

Request sample

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/organizations/{orgId}/settings' \
--header Content-Type: application/json \
--header Authorization: Bearer {accessToken} \
--header x-correlationId: {uniqueValue} \
--data-raw '[
    {
        "context": "signing",
        "configurations": [
            {
                "name": "credentials",
                "value": {
                    "certificateFileData": "Certificate .cer file encoded in Base64",
    				  "certificateFileKey": "Certificate .key file encoded in Base64",
	    			  "password": "ENTER PASSWORD HERE",
	    		       "extension": ".cer",
    				  "extensionKey": ".key"
                },
                "scope": {
                    "category": "MX_INV",
                    "productId": "mx_comprobante__4.0",
                    "orgId": "YOUR-ORG-ID",
            		  "taxId": "YOUR-COMPANY-TAXID"
                }
            }
        ]
}]'

Response sample

{
    "status": 201,
    "message": "Created",
    "success": true,
    "timestamp": 1768312093636,
    "data": [
        {
            "message": "Configurations are created",
            "statusCode": 201,
            "configurationContextResponse": {
                "context": "Signing",
                "configurations": [
                    {
                        "id": "SETTING-ID",
                        "name": "credentials",
                        "value": {
                            "certificateFileData": "ENCRYPTED .CER file",
                            "certificateFileKey": "ENCRYPTED .KEY file",
                            "password": "ENCRYPTED PASSWORD",
                            "extension": ".cer",
                            "extensionKey": ".key",
                            "certificateExpiryDate": "CERTIFICATE EXPIRATION DATE"
                        },
                        "scope": {
                            "category": "MX_INV",
                            "productId": "mx_comprobante__4.0",
                            "orgId": "YOUR-ORG_ID",
                            "taxId": "YOUR-COMPANY-TAX-ID"
                        },
                        "auditData": {
                            "createdAt": 1768312093,
                            "createdBy": user@company.com,
                            "isDeleted": false,
                            "version": 1
                        }
                    }
                ]
            }
        }
    ]
}

Update signing credentials for Mexico

  1. Send a PUT request to the endpoint URL:
    PUT https://api-test.sovos.com/v2/configurations/organizations/{orgId}/settings/{settingId}
  2. Include the following headers in your request:

    • Content-Type: application/json

    • Authorization: Bearer {accessToken}

    • x-correlationId: {uniqueValue}

  3. Optional: Include the following parameters inside the JSON payload in the request body.
    NameTypeRequiredDescription
    valueobjectYes
    certificateFileDatastringYesCertificate .cer file encoded in Base64
    certificateFileKeystringYesCertificate .key file encoded in Base64
    passwordstringYesCertificate password
    extensionstringYesUse ".cer"
    extensionKeystringYesUse ".key"

Upon successful creation, the API will return a JSON object containing the uploaded credentials and their assigned SETTING-ID.

Samples for updating signing credentials for Mexico

Request sample

curl --location --request PUT 'https://api-test.sovos.com/v2/configurations/organizations/{orgId}/settings/{settingId}' \
--header Content-Type: application/json \
--header Authorization: Bearer {accessToken} \
--header x-correlationId: {uniqueValue} \
--data-raw '{
    "value": {
        "certificateFileData": "Certificate .cer file encoded in Base64",
    	    "certificateFileKey": "Certificate .key file encoded in Base64",
	    "password": "ENTER PASSWORD HERE",
	    "extension": ".cer",
    		extensionKey": ".key"
    }
}'

Response sample

{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1667468931220,
    "data": {
        "id": "SETTING-ID",
        "name": "credentials",
        "value": {
            "certificateFileData": "Certificate .cer file encoded in Base64",
    		    "certificateFileKey": "Certificate .key file encoded in Base64",
	    	    "password": "ENTER PASSWORD HERE",
	    	    "extension": ".cer",
    		    "extensionKey": ".key"
			"certificateExpiryDate": "CERTIFICATE EXPIRATION DATE"
        },
        "scope": {
            "category": "MX_INV",
            "productId": "mx_comprobante__4.0",
            "orgId": "YOUR-ORG-ID",
            "taxId": "YOUR-COMPANY-TAXID",
		   "workspaceId": "YOUR-WORKSPACE-ID"
        },
        "auditData": {
            "createdAt": 1768312093,
            "createdBy": user@company.com,
            "updatedAt": 1770227255,
            "updatedBy": user@company.com,
            "isDeleted": false,
            "version": 3
        }
    }
}

Issue invoice

Invoice clearance in Mexico is based on the Default business process, which follows this order: Mapping, Signing, Transmission, and Distribution. The diagram below provides a detailed overview:

Overview process of Mexico outbound

Step 1: Supplier creates the Standard Business Document

Every invoice 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) or an invoice in the supported local format - except when the Local Format is used. To create the SBD, follow the detailed instructions in the SBDH, Sovos Document, and SCI pages. The following section explains some of the most important elements that you should include in the SBD and the invoice.

SCI - Invoice
NodeRequiredAttributesValue
StandardBusinessDocumentHeader.Sender.IdentifierYesAuthority="MX"
StandardBusinessDocumentHeader.Receiver.IdentifierYesAuthority="MX"
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: MX

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: 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, so as to meet the different needs. If SenderSystemId is not configured on the client side, it'll use the default value of "DefaultSystemERP". For more information, see this topic.

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: CompanyCode

Child node Identifier: Supplier's RFC

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)No

Child node Type: BusinessCategory

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 (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier: Comprobante

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: SCI-TO-LEGAL_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService. BusinessServiceNameYesDefault
SovosDocument.SovosCanonicalInvoice.InvoiceYesSCI
Local Format - Invoice
NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.StandardYeshttp://www.sat.gob.mx/cfd/3
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersionYes 3.3
StandardBusinessDocumentHeader.DocumentIdentification.TypeYesComprobante
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) No (never use) Child node Type: Mapping.OutputSchema
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) No (never use)Child node Type: Mapping.TransformDocument
SovosDocument.SovosLegalDocumentYes The CFDI invoice

Supported document types for the Local Format (XML) document:

  • "I" - "Income" for regular invoices, fee, and lease receipts

  • "E" - "Expenditure" for credit notes

  • "T" - "Transfer" for moving goods within the company with a necessity of legal possession validation

  • "N" - "Payroll" for payroll receipts and associated expenses

  • "P" - "Payment" for payment receipts etc

Note:

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

SBD sample
Below is a sample of the SBD. In addition, there's a full sample of the SBD in the Postman Samples page. 
<sbd:StandardBusinessDocument xmlns="http://uri.etsi.org/01903/v1.4.1#" 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" 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">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="MX">ABC000101000</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="MX"/>
			<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>2010-01-01T00:00:00Z</sbd:CreationDateAndTime>
		</sbd:DocumentIdentification>
		<sbd:BusinessScope>
			<sbd:Scope>
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>MX</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>Comprobante</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>CompanyCode</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>ABC000101000</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderDocumentId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>1234556</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.

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

NameTypeRequiredDescription
data string Yes The Base64-encoded SBD from step 1
dataEncoding string Yes Use "base64"
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer Gy5wXGen0aoYFxcSTCBaZG2nGsu0' \
--header 'x-correlationId: 057b5a5e-520c-4ea0-a948-9d583b4d121c' \
--data-raw '{
	"data": "PD9...de4=",
	"dataEncoding" : "base64"
}'
Response sample
{
    "timestamp": 1605282724079,
    "status": 202,
    "success": true,
    "message": "Document Received",
    "data": {
        "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf"
    }
}

Step 3: Sovos maps the SCI into CFDI

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

Note:

This step is skipped when the SBD contains the invoice in the local format (XML).

Step 4: Sovos performs the schema validation

After mapping, Sovos validates the schema to determine whether the CFDI XML file conforms to the official schema structure.

Step 5: Sovos signs the CFDI

After the CFFI passes the schema validation, Sovos signs it with the configured CSD certificate. During this operation, Sovos fills out the CFDI Comprobante element attributes "sello", "noCertificado", and "certificado".

Step 6: Sovos transmits the CFDI

Sovos transmits the signed CFDI XML file to the PCCFDI for clearance.

Step 7: PCCFDI processes the CFDI

Upon receiving the file, the PCCFDI performs the CFDI certification process.

After performing its services, the PCCFDI sends the timbre (proof of clearance) to Sovos. Sovos will put together the CFDI and the proof of clearance.

Step 8: Sovos generates the PDF

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

Step 9: Sovos distributes the PDF and the CFDI

As explained in step 11, the supplier can retrieve the CFDI XML and the PDF via a GET API request. Sovos can also distribute the PDF and the CFDI XML to the supplier using one of the following options:

  • Email

  • AS2

  • SFTP

  • Web Services

Note:

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

Step 10: Storing

Sovos stores the PDF and the CFDI XML.

Step 11: Supplier retrieves the application responses

Attachments configuration

There are three ways you can access your attachments:

  • As binary data, so the file is embedded in the Base64-encoded application response.

  • As open download links, in which the response contains a public URL to download the file.

  • As secure download links, in which you need to use the Indirect Tax API's bearer token to download the attachment.

By default, Sovos configures your attachments as open download links to avoid potential size limitations when retrieving responses. To improve security, you should configure them as secure links. Then, make a GET call to the secure link returned by the Indirect Tax API, and include the API token. Sample request:

curl --location 'https://einvoicing-api.sovos.com/download/api/v1/download/JqYyqliXiJFKhXshnBQZfW3qpfwATVGE5Q73T41JUynNLJD8zHy5VH__9qzL9No-Kia9olSw3_lNX3KmaA9Je89Xx--vk5pQjyKx0iT_4CwPSABD0Yg7uxXZ8SNiliEhFY-4TOX7m1TV5FwwfqntehbGaiGMI2JVYu18VBDiC_0/plain%27 \
--header 'Authorization: Bearer TOKEN'Y

In 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. These responses provide status information and also include a URL to access the cleared DTE and PDF once these have become 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. A successful transaction generates five application responses, as shown in the table below:

SCICloudStatusCodeSCIResponseCode
101IP
102IP
103IP
106IP
200AP or CA

The supplier can use the following COAPI endpoints to retrieve application responses:

  • GET /notifications/MX

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

GET /notifications/MX
The supplier sends a GET request to the /notifications/MX endpoint to retrieve application responses that match the set search criteria. To make this request, use the following parameters:
NameTypeRequiredDefaultDescription
taxId stringNoInclude only notifications related to the specified taxId. This value is related to the CompanyCode set in the SBDH.
pageintegerNo1To specify the page to be returned, use a value between 1 and 10.
perPageintegerNo10

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

Important:

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

sourceSystemId string YesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledged booleanNofalseUse "true" to include previously acknowledged notifications in the result.
includeBinaryData booleanNofalseUse "true" to include the binary data of the XML and PDF in the application response.
processType stringNoUse "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/MX?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}&includeBinaryData=true&processType=0' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: 057b5a5e-520c-4ea0-a948-9d583b4d121c' \
--header 'Authorization: Bearer oj3Uw1IJLVZyrc8TYmC9amh7F5Cx'
Response sample
{
    "timestamp": 1633687728708,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 2,
            "totalPages": 140,
            "totalEntries": 1399
        },
        "notifications": [
            {
                "createdDate": 1629824492,
                "metadata": {
                    "productId": "CFDI",
                    "documentId": "3428ba6600dfd042a2090390e04471ed16b1",
                    "erpDocumentId": "80257087",
                    "erpSystemId": "uat_test",
                    "processType": "0",
                    "taxId": "URE180429TM6",
                    "sciCloudStatusCode": "101",
                    "sciResponseCode": "IP",
                    "sciStatusAction": "NOA"
                },
                "appPrefix": "INV",
                "notificationId": "da3095da-f974-420c-bce2-e33682692276",
                "content": "PEF...c2U+"
            },
            {
                "createdDate": 1629857132,
                "metadata": {
                    "productId": "CFDI",
                    "documentId": "3b20cf820153a0407f0b40402482b216cd7b",
                    "erpDocumentId": "321412",
                    "erpSystemId": "uat_test",
                    "processType": "0",
                    "taxId": "URE180429TM6",
                    "sciCloudStatusCode": "102",
                    "sciResponseCode": "IP",
                    "sciStatusAction": "NOA"
                },
                "appPrefix": "INV",
                "notificationId": "6b0e273b-9ba9-43bc-9911-7eea7867786e",
                "content": "PEF...NlPg=="
            }
        ]
    }
}
GET /documents/MX/{documentId}/notifications

The supplier sends a GET request to the /documents/MX/{documentId}/notifications endpoint to retrieve application responses related to a single document.

To make this request, use the following parameters:

NameTypeRequiredParameter typeDefaultDescription
documentId string YesPathThe ID of the document returned in step 2.
includeAcknowledgedbooleanNoQueryfalseUse "true" to include previously acknowledged notifications in the result.
includeBinaryDatabooleanNoQueryfalseUse "true" to include the binary data of the XML and PDF in the application response.
Request Sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/MX/{documentId}/notifications?includeAcknowledged=true&includeBinaryData=true' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer oj3Uw1IJLVZyrc8TYmC9amh7F5Cx' \
--header 'x-correlationId: 6d49dcfe-fd6b-4fb5-a590-44f4e720d70b'
Response Sample
{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "CFDI",
                    "documentId": "0af1d17c-759a-4b93-b6f5-ad11601be390",
                    "erpDocumentId": "76059264",
                    "erpSystemId": "uat_test",
                    "processType": "0",
                    "taxId": "URE180429TM6",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "100"
                },
                "appPrefix": "INV",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}

Step 12: Supplier marks the application responses as acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. To do this, send a PUT request to the /notifications/MX endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read"
notificationIdstringYesThe notification ID
Note:

Multiple notificationId values can be acknowledged using 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/MX' \
--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."
}

Supplier sends the CFDI and the PDF to the Buyer

As the final step, the supplier should send the CFDI XML and optionally the PDF to the buyer through an agreed-upon channel. This process is outside the scope of Sovos.

Cancel invoice

The following diagram provides a detailed overview of the invoice cancellation process in Mexico:

Overview process for invoice cancellation in Mexico

Step 1: Supplier sends a POST request to Sovos

The supplier sends a POST request to the /documents/MX/action endpoint. To make this request, set the following request body parameters:

NameTypeRequiredDescription
actionCodestringYesUse "document.cancellation".
documentsarray of objectsYes
metadataobjectNo
reasonstringNoThe reason for canceling the invoice. For the SAT cancellation codes, see the the Proceso de cancelación page.
documentIdstringYesThe documentId that Sovos returns when you send the document.
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents/MX/action' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '  {
    "actionCode": "document.cancellation",
    "documents": [
      {
        "metadata": {
            "reason": "{reason}",
            "documentReferenceID": "{documentReferenceID}"
        },
        "documentId": "{documentId}"
      }
    ]
  }'
Response sample
{
    "timestamp": 1605632952347,
    "status": 202,
    "success": true,
    "message": "Action Received",
    "data": [
        {
            "documentId": "62b6c12e08264046960a35e00b5ed9d11d97"
        }
    ]
}

Step 2: Sovos extracts the folio

Sovos extracts the folio number from the invoice to be canceled, because this information is required for the cancellation request.

Step 3: Sovos transmits the cancellation

Sovos transmits the cancellation request to the PCCFDI.

Step 4: PCCFDI performs the validation

The PCCFDI validates the cancellation request to see whether the invoice has been cleared.

Step 5: PCCFDI transmits the cancellation

After performing the validation, the PCCFDI transmits the cancellation request to the SAT.

Step 6: SAT processes the cancellation

SAT processes the cancellation request. In most cases, SAT must request authorization from the buyer before it can confirm the cancellation. This means that SAT initiates pre-cancellation, which is essentially an intermediary state that must await acceptance or rejection from the buyer before it may progress to the final state. The buyer has 72 business hours to accept or reject the cancellation. After that, the acceptance becomes implicit.

Step 7: SAT returns the response

The acceptance or rejection message is then returned to Sovos through the PCCFDI.

Step 8: Supplier retrieves the application responses

Attachments configuration

There are three ways you can access your attachments:

  • As binary data, so the file is embedded in the Base64-encoded application response.

  • As open download links, in which the response contains a public URL to download the file.

  • As secure download links, in which you need to use the Indirect Tax API's bearer token to download the attachment.

By default, Sovos configures your attachments as open download links to avoid potential size limitations when retrieving responses. To improve security, you should configure them as secure links. Then, make a GET call to the secure link returned by the Indirect Tax API, and include the API token. Sample request:

curl --location 'https://einvoicing-api.sovos.com/download/api/v1/download/JqYyqliXiJFKhXshnBQZfW3qpfwATVGE5Q73T41JUynNLJD8zHy5VH__9qzL9No-Kia9olSw3_lNX3KmaA9Je89Xx--vk5pQjyKx0iT_4CwPSABD0Yg7uxXZ8SNiliEhFY-4TOX7m1TV5FwwfqntehbGaiGMI2JVYu18VBDiC_0/plain%27 \
--header 'Authorization: Bearer TOKEN'Y

In 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 will also include the acceptance or rejection message.

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/MX

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

GET /notifications/MX

The supplier sends a GET request to the /notifications/MX endpoint to retrieve application responses that match the set search criteria. To make this request, use the following parameters:

NameTypeRequiredDefaultDescription
taxIdstringNo Include only notifications related to the specified tax ID. This value is related to the CompanyCode in the SBDH.
page integerNo1 To specify the page to be returned, use a value between 1 and 10.
perPage integerNo10

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

Important:

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

sourceSystemIdstringYes Include only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalse Use "true" to include previously acknowledged notifications in the result.
includeBinaryDatabooleanNofalseUse "true" to include the binary data of the XML and PDF in the application response.
processTypestringNo Use "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/MX?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}&includeBinaryData=true&processType=0' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: 057b5a5e-520c-4ea0-a948-9d583b4d121c' \
--header 'Authorization: Bearer oj3Uw1IJLVZyrc8TYmC9amh7F5Cx'
Response sample
{
    "timestamp": 1633687728708,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 2,
            "totalPages": 140,
            "totalEntries": 1399
        },
        "notifications": [
            {
                "createdDate": 1629824492,
                "metadata": {
                    "productId": "FE",
                    "documentId": "3428ba6600dfd042a2090390e04471ed16b1",
                    "erpDocumentId": "80257087",
                    "erpSystemId": "uat_test",
                    "processType": "0",
                    "taxId": "URE180429TM6",
                    "sciCloudStatusCode": "101",
                    "sciResponseCode": "IP",
                    "sciStatusAction": "NOA"
                },
                "appPrefix": "INV",
                "notificationId": "da3095da-f974-420c-bce2-e33682692276",
                "content": "PEF...c2U+"
            },
            {
                "createdDate": 1629857132,
                "metadata": {
                    "productId": "FE",
                    "documentId": "3b20cf820153a0407f0b40402482b216cd7b",
                    "erpDocumentId": "321412",
                    "erpSystemId": "uat_test",
                    "processType": "0",
                    "taxId": "URE180429TM6",
                    "sciCloudStatusCode": "102",
                    "sciResponseCode": "IP",
                    "sciStatusAction": "NOA"
                },
                "appPrefix": "INV",
                "notificationId": "6b0e273b-9ba9-43bc-9911-7eea7867786e",
                "content": "PEF...NlPg=="
            }
        ]
    }
}
GET /documents/MX/{documentId}/notifications
The supplier sends a GET request to the /documents/MX/{documentId}/notifications endpoint to retrieve application responses related to a single document.

To make this request, use the following parameters:

NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPath The document ID returned in step 1
includeAcknowledgedbooleanNo QueryfalseUse "true" to include previously acknowledged notifications in the result
includeBinaryDatabooleanNo QueryfalseUse "true" to include the binary data of the XML and PDF in the application response
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/MX/{documentId}/notifications?includeAcknowledged=true&includeBinaryData=true' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer oj3Uw1IJLVZyrc8TYmC9amh7F5Cx' \
--header 'x-correlationId: 6d49dcfe-fd6b-4fb5-a590-44f4e720d70b'
Response sample
{
    "timestamp": 1633685509314,
    "status": 200,
    "success": true,
    "message": "Notifications Listed",
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 50,
            "totalEntries": 1
        },
        "notifications": [
            {
                "createdDate": 1633681296,
                "metadata": {
                    "productId": "CFDI",
                    "documentId": "0af1d17c-759a-4b93-b6f5-ad11601be390",
                    "erpDocumentId": "76059264",
                    "erpSystemId": "uat_test",
                    "processType": "0",
                    "taxId": "URE180429TM6",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "100"
                },
                "appPrefix": "INV",
                "notificationId": "a8dc1aa2-fbe6-45ce-9e4c-97a3d5fdb91c",
                "content": "PEF...NlPg=="
            }
        ]
    }
}

Step 9: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. To do this, send a PUT request to the /notifications/MX endpoint.

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

NameTypeRequiredDescription
statusstringYesUse "read"
notificationIdstringYesThe notification ID
Request sample 
curl --location --request PUT 'https://api-test.sovos.com/v1/notifications/MX' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer oj3Uw1IJLVZyrc8TYmC9amh7F5Cx' \
--header 'x-correlationId: 6d49dcfe-fd6b-4fb5-a590-44f4e720d70b'
--data-raw '[
    {
        "status": "read",
        "notificationId": "51341d39-fd3e-4dcf-aea3-a73d73e0de76"
    }
]'
Response sample
{
    "timestamp": 1601673284,
    "status": 200,
    "success": true,
    "message": "Notifications acknowledged successfully."
}

Consultations

The following diagram gives a detailed overview of the process for Consultations in Mexico based on the Default business process:

Mexico consultations

Step 1: Sender creates Standard Business Document

Every invoice 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. The following section explains some of the most important elements that you should include in the SBD and the invoice.

SCI - Invoice
NodeRequiredAttributesValue
StandardBusinessDocumentHeader.Sender.Identifier YesAuthority="MX" Supplier's RFC
StandardBusinessDocumentHeader.Receiver.Identifier YesAuthority="MX"
StandardBusinessDocumentHeader.DocumentIdentification.Standard Yes urn:oasis:names:specification:ubl:schema:xsd:Invoice-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersion Yes 2.1
StandardBusinessDocumentHeader.DocumentIdentification.Type Yes Invoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Country

Child node Identifier: MX

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: 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, so as to meet the different needs. If SenderSystemId is not configured on the client side, it'll assume the default value of "DefaultSystemERP". For more information, see this topic.

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: CompanyCode

Child node Identifier: Supplier's RFC

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)No

Child node Type: BusinessCategory

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 (with child nodes) Yes

Child node Type: Mapping.OutputSchema

Child node Identifier: Comprobante

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: SCI-TO-LEGAL_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceName YesDefault
SovosDocument.SovosCanonicalInvoice.Invoice YesSCI
Local Format - Invoice

Alternatively, the supplier can use the local format (XML) instead of SCI. To do this, the SBD must be created with the following differences compared to when using the SCI:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.StandardYeshttp://www.sat.gob.mx/cfd/3
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersionYes3.3
StandardBusinessDocumentHeader.DocumentIdentification.TypeYes Comprobante
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) No (never use)Child node Type: Mapping.OutputSchema
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes) No (never use) Child node Type: Mapping.TransformDocument
SovosDocument.SovosLegalDocumentYes The CFDI invoice
Note:

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

SBD sample
<?xml version="1.0" encoding="UTF-8"?>
<sbd:StandardBusinessDocument xmlns:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="MX">FUNK671228PH6</sbd:Identifier>
		</sbd:Sender>
		<sbd:BusinessScope>
			<sbd:Scope>
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>MX</sbd:Identifier>
			</sbd:Scope>
		</sbd:BusinessScope>
	</sbd:StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<svs:SovosLegalDocument>
			<svs:LegalSchema>
				<cfdi:Comprobante xmlns:cfdi="http://www.sat.gob.mx/cfd/3">
					*Legal Document Content*
				</cfdi:Comprobante>
			</svs:LegalSchema>
		</svs:SovosLegalDocument>
	</svs:SovosDocument>
</sbd:StandardBusinessDocument>

Step 2: Sender sends SBD to Sovos

The customer sends a POST request to the /consultations endpoint.

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

NameTypeRequiredDescription
consultationCodestringYes Use "document.validation" to make a validation on the CFDI
ProductidstringYes Use "MX_BusinessToBusiness_Consultations_V1.0"
documentsarray of objectsNo
documentDatastringNo The SBD and the document encoded in Base64
dataEncodingstringNo Use "base64"
Request sample
curl --location --request POST 'https://api-test-tls.sovos.com/v1/consultations' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
    "consultationCode": "document.validation",
    "productId": "MX_BusinessToBusiness_Consultations_V1.0",
    "documents": [
        {
            "metadata": {
                "trackId": "test"
            },
            "dataEncoding": "base64",
            "data": "PD94...bnQ+"
        }
    ]
}'
Response sample

Here's a response sample with no errors in the validation:

{
    "status": 202,
    "message": "Document received",
    "timestamp": 1676052321871,
    "data": {
        "completed": true,
        "nextPollInSeconds": 0,
        "jobState": null,
        "detailsDto": {
            "completed": "DONE",
            "messages": [
                {
                    "code": "200",
                    "message": "Document verified successfully"
                }
            ],
            "documents": [],
            "keys": [
                {
                    "key": "LegalCleared",
                    "value": "http://qa2.reachcore.io/Portal/Documentos?x=eisPj82nX0gKSClnl8GI3JFRZMPINRn3ieMNGcBC6%252F0dlRpPmVSvFZFGG8PTlmNDivXjFH6h61%252Ba86mfEeSghxhJGs3V2qaUjBbmgC%252B44EB9fYUkJmLf1Trt9pijwZZEsZeXdCB8x6%252BZASRKoNcdJ1wN90av6swu0rev3aXWr4BP2CiDWPf2qHDDcSeGdJSUYaLJHhpfGafKyphdKxSk7vRSu6eFLpuvAjU0s6lOhjRmJqvYGSDaLA%253D%253D"
                },
                {
                    "key": "PDF",
                    "value": "http://qa2.reachcore.io/Portal/Documentos?x=eisPj82nX0gKSClnl8GI3JFRZMPINRn3ieMNGcBC6%252F0dlRpPmVSvFZFGG8PTlmNDivXjFH6h61%252Ba86mfEeSghxhJGs3V2qaUjBbmgC%252B44EB9fYUkJmLf1Trt9pijwZZEeWBDpJVeN8A4yoIXpMxRg7zr%252F9sj5WDfGdoKrThOnp%252BZ6AgL0P1NeBa9MVVGERswT9Gv7SxS735la%252B%252FAudi8PHNrlFsJiYw16MBnBJ9MAm63Cl2vJKBRSA%253D%253D"
                },
                {
                    "key": "UUID",
                    "value": "C516576A-B230-4E50-BE9F-15F06CF9D9A8"
                }
            ],
            "errors": []
        }
    },
    "success": true
}

Here's a response sample with errors in the validation: 

{
    "status": 202,
    "message": "Document received",
    "timestamp": 1676051628945,
    "data": {
        "completed": true,
        "nextPollInSeconds": 0,
        "jobState": null,
        "detailsDto": {
            "completed": "DONE",
            "messages": [
                {
                    "code": "400",
                    "message": "Errors were found while performing validation"
                }
            ],
            "documents": [],
            "keys": [],
            "errors": [
                {
                    "code": "CF-CFDI-0003",
                    "message": "No se encontró el elemento timbre fiscal digital en el nodo Complemento del comprobante"
                },
                {
                    "code": "CF-CFDI-0014",
                    "message": "No existe el TFD."
                },
                {
                    "code": "CF-CFDI-0015",
                    "message": "El atributo 'Sello' del comprobante, es diferente al atributo 'SelloCFD' que se encuentra en el complemento timbre Fiscal."
                },
                {
                    "code": "203",
                    "message": "No se encontró el nodo TimbreFiscalDigital'."
                }
            ]
        }
    },
    "success": true
}

Step 3: Sovos identifies the consultation

Sovos receives and identifies the requested consultation type. Sovos proceeds to forward it to the PCCFDI.

Step 4: Sovos sends the request to the PCCFDI

Sovos sends the consultation request to the corresponding PCCFDI service.

Step 5: PCCFDI processes the request and returns the response

PCCFDI processes the consultation request and returns the response to Sovos.

Step 6: Sovos returns the response to the sender

Sovos communicates the PCCFDI's response to the sender.

Check tax ID

The diagram below provides a detailed overview of the process for verifying a tax ID in Mexico based on the Default business process:

Tax ID check workflow in Mexico

Step 1: Requester sends a Tax ID verification request

The requester sends a POST request to the /taxid-checks/MX endpoint.

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

NameTypeRequiredDescription
taxIdstringNo The tax ID you want to validate
countryCodestringNo Use "MX"
requesterobjectNo
taxIdstringNo The requester's tax ID
Request Sample
curl --location --request POST 'https://api-test-tls.sovos.com/v1/taxid-checks/MX' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--header 'Content-Type: application/json' \
--data-raw '{
    "taxId": "XIA190128J61",
    "countryCode": "MX",
    "requester": {
        "taxId": "AAB1011024L8"
    }
}'
Response Sample
{
	"status": 202,
	"message": "success",
	"timestamp": 1676638006079,
	"data": {
		"taxId": "AAB1011024L8",
		"legalName": "ASESORES ADMINISTRATIVOS BAIK S.A. DE C.V.",
		"additionalData": {
			"queryDate": "2023-02-17T06:46:45",
			"found": "Si",
			"statusTaxIds": [
				{
					"statusKey": "situacion",
					"statusValue": "Definitivo"
				},
				{
					"statusKey": "noOficioPresuncion",
					"statusValue": "500-05-2014-16093 de fecha 30 de abril de 2014"
				},
				{
					"statusKey": "fechaSATPresuncion",
					"statusValue": "2014-05-01T00:00:00"
				},
				{
					"statusKey": "fechaDOFPresuncion",
					"statusValue": "2014-05-15T00:00:00"
				},
				{
					"statusKey": "fechaDOFDefinitivos",
					"statusValue": "2015-03-16T00:00:00"
				},
				{
					"statusKey": "noOficioSentenciaFavorable",
					"statusValue": "500-05-2015-7905 de fecha 16 de marzo de 2015?"
				},
				{
					"statusKey": "fechaSATSentenciaFavorable",
					"statusValue": "2015-04-06T00:00:00"
				}
			]
		}
	},
	"success": true
}

Step 2: Sovos transmits the request to the PCCFDI

Sovos receives and identifies the request, then forwards it to the PCCFDI.

Step 3: PCCFDI performs the validation

The PCCCFDI validates the tax ID against the list 69B (blocklist).

Step 4: Sovos returns the response to the requester

Sovos communicates the PCCFDI's response to the requester.

Mexico
Compliance Network
PDF

Last updated: February 13, 2026

sovos-footer

The Always-On Tax Compliance Company

More than 100,000 customers – including half the Fortune 500 – trust Sovos' tax and regulatory expertise and unparalleled integration with their business applications.

Contact Support

Sovos Platform

Compliance Cloud

Indirect Tax Suite

Compliance for SAP

Product Suites

Value-Added Tax

Tax Information Reporting

Sales and Use Tax

For Developers

Connector Marketplace

Trust APIs

© 2025 Sovos Compliance. All rights reserved.

Privacy Policy

About Us