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) - except when the Local Format is used. To create the SBD, follow the detailed instructions in the SBDH, Sovos Document, and SCI pages. In addition, we'll now take a closer look at some key elements within the SBD:

SBD Sample

Below is a sample of the SBD. In addition, there's a full sample of the SBD in the Postman Samples page and the orange "Run in Postman" buttons on this 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, set the following request body parameters:

Step 3: Sovos maps the SCI into CFDI

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

Step 4: Sovos performs the schema validation

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

Step 5: Sovos signs the CFDI

After the CFFI passes the schema validation, Sovos signs it with the configured CSD certificate. The CFDI Comprobante element attributes sello, noCertificado and certificado will be filled in during this operation.

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 will perform the clearance process (Timbrado, in Spanish), which includes a schema validation and several content validations, including the supplier's signature. The PCCFDI then clears it by generating an XML complemento that contains the PCCFDI signature, a PCCFDI-assigned unique invoice number (folio fiscal, in Spanish) tagged as a UUID, the date, and other complementary data. All these fields together constitute the proof of clearance (Timbre, in Spanish).

After performing its services, the PCCFDI sends the 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. But Sovos can also distribute the PDF and the CFDI XML to the supplier using one of the following options:

• Email

• AS2

• SFTP

• Web Services

Step 10: Storing

Sovos stores the PDF and the CFDI XML.

Step 11: Supplier Retrieves the Application Responses

It is highly recommended that clients configure their Application Response attachments as download links instead of base64 encoded data to avoid potential size limitations when retrieving responses. The default option is download links.

• When using download links the response contains a URL from where the file can be downloaded.

• When using binary data, the file itself is embedded in the response encoded in base64.

This configuration is available through our Professional Services team.

As a response to the initial sending of the document, the client will receive 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 will generate five application responses, as shown in the table below:

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

• GET /notifications/MX

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

Step 12: Supplier Marks the Application Responses as Acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/MX endpoint.

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

Step 1: Supplier sends the POST request to Sovos

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

Request body parameters:

Step 2: Sovos extracts the Folio

Sovos extracts the folio number from the invoice to be canceled, as 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

The SAT processes the cancellation request. In the majority of cases, the SAT must request authorization from the buyer before it can confirm the cancellation. This means that the 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

It is highly recommended that clients configure their Application Response attachments as download links instead of base64 encoded data to avoid potential size limitations when retrieving responses. The default option is download links.

• When using "download links" the response contains a URL from where the file can be downloaded.

• When using "binary data", the file itself is embedded in the response encoded in base64.

This configuration is available through our Professional Services team.

As a response to the initial sending of the document, the client will receive 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 COAPI endpoints to retrieve application responses:

• GET /notifications/MX

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

Step 9: Supplier marks the Application Responses as Acknowledged

After retrieving application responses, the supplier must process them and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/MX endpoint.

Request body parameters:

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. In addition, we'll now take a closer look at some key elements within the SBD:

Step 2: Sender sends SBD to Sovos

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

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

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 processes the request with the PCCFDI.

Sovos properly routes the consultation request to the corresponding PCCFDI service.

Step 5: The PCCFDI sends a response

The PCCFDI processes the Consultation request and returns the response to Sovos.

Step 6: Sovos returns the response to the Customer.

Sovos communicates the PCCFDI's response to the Sender.

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, set the following request body parameters:

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 performs the validation of 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.