e-invoicing

Standard Business Document Header

The Standard Business Document Header (SBDH) provides the semantic information required for the routing, processing, and business domain context of documents.

The SBDH is an integral part of the XML instance. In practice, this means that, in the Standard Business Document, the StandardBusinessDocumentHeader element must be included within the root element of the message, along with the Sovos Document element.

The following table lists the different SBDH Xpaths:

SBDH XPath Type # Description
StandardBusinessDocumentHeader object 1..1 The UN/CEFACT standard, containing information about the routing and processing of the business document.
HeaderVersion string 1..1 Version number of the SBDH standard used, which must always be "1.0".
Sender object 1..* This block has information about the transaction's supplier or taxpayer.
Identifier string 1..1 The tax ID of the supplier or taxpayer.
Authority string 0..1 Attribute for the country code of the transaction's jurisdiction, following the ISO 3166-1 alpha-2 standard.
ContactInformation object 0..* Contact information of the supplier or taxpayer.
Contact string 0..1 The company ID from the supplier or taxpayer. In some cases, this must be the companyId, as registered during the configuration process.
EmailAddress string 0..1 The email address of the supplier or taxpayer.
FaxNumber string 0..1 The fax number of the supplier or taxpayer. Example: +1-212-555-1213.
TelephoneNumber string 0..1 The telephone number of the supplier or taxpayer. Example: +1-212-555-2122.
ContactTypeIdentifier string 0..1 The role of the identifier on the supplier or taxpayer side.
Receiver object 0..* As the receiver is always the buyer in the transaction, this block contains buyer information.
Identifier string 1..1 The tax ID of the buyer.
Authority string 0..1 Attribute for the country code of the transaction's jurisdiction, following the ISO 3166-1 alpha-2 standard.
ContactInformation object 0..* Contact information of the buyer.
Contact string 0..1 The company ID of the buyer. In some cases, this must be set to the companyId, as registered during the configuration process.
EmailAddress string 0..1 The email address of the buyer.
FaxNumber string 0..1 The fax number of the buyer. Example: +1-212-555-1213.
TelephoneNumber string 0..1 The telephone number of the buyer. Example: +1-212-555-2122.
ContactTypeIdentifier string 0..1 The role of the identifier on the buyer side.
DocumentIdentification object 1..1 Identification information for the document.
Standard string 1..1 This element specifies the XSD schema for the type of document. The following values should be used, depending on the type of business document:
  • "urn:oasis:names:specification:ubl:schema:xsd:Invoice-2"
  • "urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2"
  • "urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2"
  • "urn:oasis:names:specification:ubl:schema:xsd:FreightInvoice-2"
  • "urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2"
  • "urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
Note: When using the local format, this must be set to the local format's schema.
TypeVersion string 1..1 Version information of the document included in the payload of SBD. This is the version of the document itself and is different from the HeaderVersion. This value must be set to "2.1" when using SCI. Note: When using the local format, you must set it to the version of the local format used.
InstanceIdentifier string 1..1 This element must be present, and it is best practice to be set to a description which contains reference information which uniquely identifies this instance of the Standard Business Document (SBD). This identifier identifies this document as being distinct from others. Example: MSG-1645000099. Note: Although an empty value for description does work, Sovos recommends using a unique value for each instance.
Type string 1..1 The name of the XML element that defines the root of the SCI. Possible values: Invoice, CreditNote, DebitNote, Attachment, FreightInvoice, or ApplicationResponse. Note: When using the local format, choose a value that is applicable to that format.
MultipleType boolean 0..1 Flag to indicate that there's more than one type of document in the payload of the SBDH. Sovos supports only one document to be sent within one SBD, so this element must always be set to False.
CreationDateAndTime string 1..1 Date and time of the SBDH document creation. Example: 2003-05-02T00:31:52Z.
Manifest object 0..1 This element describes the attachments (i.e., binary files), if any, being sent in this package.
NumberOfItems integer 1..1 The count of the number of attachments associated with this package.
ManifestItem object 1..* Provides information about the referenced item. Repeatable if there is more than one item or attachment.
MimeTypeQualifierCode string 1..1 The MIME type as defined by IANA. Refer to http://www.iana.org/assignments/ media-types for a list of types.
UniformResourceIdentifier string 1..1 Refers to the attachment, and must always be set to #Attachment{number}. For example, the first attachment will have the value #Attachment1.
Description string 0..1 Description of the item. For example, Attachment.
BusinessScope object 0..1 This element provides a basis to determine which rules are applicable to the transaction involving the enclosed documents.
Scope object 0..* This element determines a processing rule. For each processing rule, a different Scope node must be used. Note: The BusinessProcess scope is mandatory, while other scopes are optional, used only in certain specific cases, or both. The Scopes and the Additional Scope Information tables specify the possible scopes.
Type string 1..1 This element specifies the processing rule that must be applied. Note: The Scopes and the Additional Scope Information table specify the possible values.
InstanceIdentifier string 1..1 This element provides extra information related to the processing rule.
Identifier string 0..1 This element specifies the specific value of the processing rule. Note: The Scopes and the Additional Scope Information tables specify the possible scopes.
BusinessService object 0..1 This element specifies the microservices to be consumed. Note: The BusinessService node is always grouped along with the BusinessProcess Scope.
BusinessServiceName string 0..1 This element specifies which microservices will be consumed and thus the process flow. Note: The BusinessServices table specifies the possible values.

SBDH scopes

Each Standard Business Document Header (SBDH) must contain several scopes that are informed via the BusinessScope.Scope.Type node. The BusinessProcess scope is always required, while the other scopes are not mandatory for all countries and functionalities.

Note:

In the country-specific integration guides, we explain which scopes must be used in which cases.

The following table lists all the available SBDH scopes:

Scope.Type Scope.Identifier #
CompanyCode The tax ID of the company sending the request. 0..1
SenderDocumentId The unique ID used to identify the sender's document. The value content is not constrained, but Sovos recommends using the unique ERP document identification. 0..1
SenderSystemId The sender's system ID, used to create the document. Examples of used values are: "Sandboxes1", "Development2", "SAPUAT", "SAPERC", etc. 0..1
Country The country code of the current business scope, where the invoice originates, following the ISO 3166-2 format. This information is used to target the destination services to be consumed. 0..1
ProcessType Use "Outbound" for sending a document and "Inbound" when issuing a previously received document. 0..1
BusinessCategory The category of the document. This can be set to either "BusinessToBusiness" or "BusinessToConsumer". If not provided, the value will be "BusinessToBusiness". 0..1
BusinessProcess BusinessProcess has no Identifier node. Instead, it must be grouped along with the BusinessService node. 1..*
Version The current version supported or provided by the tax authority. If not provided, the default value will be "1.0". 1..*
SubSchema Use when the tax authority's invoice structure is more complex, so as to provide a better classification. When unneeded, use the value "-" (hyphen). 1..*

About SenderSystemId​

The default value for SenderSystemId​ is "DefaultSystemERP". This value is meant to simplify onboarding and reduce setup time and has the following advantages:

  • Prebuilt with all necessary event types and attachment types.

  • Compliance coverage for all supported countries.

  • Uses URLs to return attachments rather than binary payloads.

  • Ready to use, so you don't need to make any configurations.

  • Supports incoming and outgoing document flows.

  • By using this default value in inbound polling, you can retrieve inbound notifications by using "DefaultSystemERP" as the value of the sourceSystemId parameter in your requests.

  • If needed, you can ask Support to clone it for customization purposes, so you can have different events or attachment types.

Important:

If you already have a working integration using the old "SystemERP" value, you can keep it as is.

Sample

CODE
<sbd:Scope>
    <sbd:Type>Country</sbd:Type>
    <sbd:InstanceIdentifier/>
    <sbd:Identifier>MX</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
    <sbd:Type>SenderDocumentId</sbd:Type>
    <sbd:InstanceIdentifier/>
    <sbd:Identifier>ID12345</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>Version</sbd:Type>
    <sbd:InstanceIdentifier/>
    <sbd:Identifier>1.0</sbd:Identifier>
</sbd:Scope>
<sbd:Scope>
    <sbd:Type>SubSchema</sbd:Type>
    <sbd:InstanceIdentifier/>
    <sbd:Identifier>-</sbd:Identifier>
</sbd:Scope>

Business Services scope

The BusinessProcess scope is a required element in every Standard Business Document Header (SBDH). This element must contain additional elements, namely the BusinessService with the child element BusinessServiceName, which determines the microservices that will be applied to the document. This also determines whether a bundled or a granular approach will be followed — bundled when Default is used as the value, and granular for all the other values.

The following table lists all the available business services:

BusinessService.BusinessServiceName Description
Default The default process for the specified country/document.
Mapping The process of mapping the SCI in the required local format or vice versa.
Determination The process of determining the tax on given line items.
Signing The process of applying an electronic signature.
SignatureValidation The process of validating the authenticity and integrity of the signature.
Transmission The process of sending the invoice to the government authorities. Depending on the country, the invoice will go past several checks and controls.
Reporting The process of reporting VAT.
Distribution The process of distributing documents to a recipient.
Archiving The process of compliantly archiving the invoice.

Sample

CODE
<sbd:Scope>
    <sbd:Type>BusinessProcess</sbd:Type>
    <sbd:InstanceIdentifier/>
    <sbd:BusinessService>
        <sbd:BusinessServiceName>Mapping</sbd:BusinessServiceName>
    </sbd:BusinessService>
</sbd:Scope>
<sbd:Scope>
    <sbd:Type>BusinessProcess</sbd:Type>
    <sbd:InstanceIdentifier/>
    <sbd:BusinessService>
        <sbd:BusinessServiceName>Signing</sbd:BusinessServiceName>
    </sbd:BusinessService>
</sbd:Scope>

Additional scope information

The Standard Business Document Header (SBDH) can include additional scopes. Each additional scope has a prefix that refers to the BusinessService. When you use the referred BusinessService (or Default, in case that BusinessService is part of the default flow), you must also add the additional scope information with the matching prefix in the SBDH.

As an example, suppose you use Mapping as your BusinessService. In that case, you must use Mapping.TransformDocument and Mapping.Outschema to provide additional scope information.

The following table lists all the additional scopes:

Scope.Type Scope.Identifier # Description
Mapping.TransformDocument Example: SCI_to_GST 1..1 The specific transform to apply when mapping this document. Note: The values differ per country and are explained in the country-specific sections.
Mapping.OutputSchema Example: GSTInvoice 1..1 The specific XML schema that is expected as the output of the mapping process. Note: The values differ per country and are explained in the country-specific sections.
Archiving.DocumentFormat Examples: PDF, XML and CXML 1..1 The format of the document to be stored. See the Archiving section for the possible values.
Archiving.InitialContentEncoding MIME 0..1 This element specifies if the initial document has any additional encoding. Initial document refers to the document before Sovos has applied any signature. Currently, MIME is the only supported value, and it can be used with unsigned documents to indicate that the provided content is MIME encoded. If the value MIME is used with an S/MIME signed document, it indicates that the content was already MIME encoded before Sovos signed it. For any other document structure, this element must be omitted.
Archiving.SignatureType Implicit, Explicit or Audit 0..1 Specifies the signature type. See the Archiving section for more information.
Archiving.SignatureFormat Examples: PDF, XMLSIG, and PKCS7 0..1 Specifies the signature format. See the Archiving section for the possible values.
Archiving.AuditCategory Examples: XADESA, PADESEPES, and EVIDENCE 0..1 Specifies the audit category. See the Archiving section for the possible values.
Archiving.Explicit.DetachedSignature Base64-encoded string 0..1 The detached signature encoded in Base64.
Archiving.Audit.AuditData Base64-encoded string 0..1 The detached audit data encoded in Base64. If you omit this element, you do not get audit data.
Archiving.CustomProperty Any metadata can be used here. Note that the child node Scope.InstanceIdentifier must be present and set to a category when this element is being used. 0..7 This complex type represents a custom property, which is basically a name-value-pair.
Archiving.CustomNumericProperty Any numeric metadata can be used here. Note that the child node Scope.InstanceIdentifier must be present and set to a category when this element is being used. 0..7 This complex type represents a custom numeric property, which is basically a name-value-pair with a numeric value.
Archiving.StoragePeriodOverride Example: 2020-05-01T12:00:00Z 0..1 The storage period end date. The date has to be at least 3 days into the future. Warning: setting an incorrect storage period end date may cause the document to be deleted before its legally regulated life-time. Use this feature carefully and at your own risk.
Archiving.AdditionalOutput DepositInfo 0..1 Specifies what additional outputs the response should include.
Archiving.StoreFor Supplier or Buyer 1..2 Specifies if the invoice should be stored for this invoicing party. Note: If the invoice must be stored for both parties, this element should be included one time for the Supplier and one time for the Buyer.
Archiving.OriginalInvoiceNumber String of the invoice number 0..1 The invoice number of the original invoice referred to by the invoice being stored. This can, for example, be used when storing credit notes and corrective invoices.
Archiving.PurchaseOrderNumber String of the purchase order number 0..5 The purchase order numbers associated with the invoice.
Signing.DocumentFormat Examples: PDF, XML and CXML 1..1 The format of the document to be signed.
Signing.InitialContentEncoding MIME 0..1 This element specifies if the initial document has any additional encoding. Initial document refers to the document before Sovos applied any signature. Currently, MIME is the only supported value, and it can be used with unsigned documents to indicate that the provided content is MIME encoded. If the value MIME is used with an S/MIME signed document, it indicates that the content was already MIME encoded before being signed by Sovos. For any other document structure, this element must be omitted.
Signing.SignatureType Implicit, Explicit or Audit 1..1 Specifies the signature type.
Signing.SignatureFormat Examples: PDF, XMLSIG and PKCS7 1..1 Specifies the signature format that must be applied to the invoice.
Signing.AuditCategory Examples: XADESA, PADESEPES and EVIDENCE 0..1 Specifies the audit category.
Signing.SignFor Sender or Receiver 1..1 Specifies if the invoice should be signed on behalf of the sender or the receiver.
Signing.PDFSignatureOrigin
  • Cartesian coordinates of the signature
  • Example: 100,100
0..1 Including this will generate a visible signature on the first page of the PDF. The specified coordinates determine the exact position. Note: This can only be used for PDF invoices, and it's only recommended for Indian invoices.
Signing.CreateAuditDetails true or false 0..1 If this element is true, the audit details will be included in the response.
SignatureValidation.InitialContentEncoding MIME 0..1 This element specifies if the initial document has any additional encoding. Initial document refers to the document before Sovos applied any signature. Currently, MIME is the only supported value, and it can be used with unsigned documents to indicate that the provided content is MIME encoded. If the value MIME is used with an S/MIME signed document, it indicates that the content was already MIME encoded before being signed by Sovos. For any other document structure, this element must be omitted.
SignatureValidation.SignatureType Implicit, Explicit, or Audit 1..1 Specifies the signature type that has been applied to the invoice.
SignatureValidation.Explicit.DetachedSignature Base64-encoded string 0..1 If SignatureValidation.SignatureType is set to "Explicit", this element must be present and contain the detached signature encoded in Base64.
SignatureValidation.Audit.AuditData Base64-encoded string 0..1 If SignatureValidation.SignatureType is set to "Audit", this element may be present. It contains the detached audit data encoded in Base64.
SignatureValidation.SignatureFormat Examples: PDF, XMLSIG, and PKCS7 1..1 Specifies the signature format applied to the invoice.
SignatureValidation.AuditCategory Examples: XADESA, PADESEPES, and EVIDENCE 0..1 Specifies the audit category.
SignatureValidation.ValidateFor Sender or Receiver 1..1 Specifies if the signature should be validated on behalf of the sender or the receiver.
SignatureValidation.NewAuditData Examples: CADESA or PADESLTV 0..1 This element allows creating new audit data. This can be the case when no audit data is present or when audit data gets promoted (for example, from CAdES-T to CAdES-A).
SignatureValidation.CreateAuditDetails true or false 0..1 If this element is "true", the audit details will be included in the response.
Transmission.OperationType
Default value
"CREATE"
Other values
"MODIFY" and "CANCEL"
1..1 Depending on the value provided, it will trigger the appropriate reporting flow. "CREATE" is used as Default in applicable markets, but other options are also "CANCEL" and "MODIFY" in those markets. For more information, refer to the country-specific pages.
Note:

For additional information, see the the post-audit page.

The specific pages for each country and product explain in detail which nodes and parameters to use in which case.

Sample

CODE
<sbd:Scope>
    <sbd:Type>BusinessProcess</sbd:Type>
    <sbd:InstanceIdentifier/>
    <sbd:BusinessService>
        <sbd:BusinessServiceName>Mapping</sbd:BusinessServiceName>
    </sbd:BusinessService>
</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>

Standard Business Document Header sample

CODE
<sbd:StandardBusinessDocumentHeader>
	<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
	<sbd:Sender>
		<sbd:Identifier Authority="IN">08AAACI9260R002</sbd:Identifier>
		<sbd:ContactInformation>
			<sbd:Contact>08AAACI9260R002</sbd:Contact>
			<sbd:EmailAddress/>
			<sbd:FaxNumber/>
			<sbd:TelephoneNumber/>
			<sbd:ContactTypeIdentifier/>
		</sbd:ContactInformation>
	</sbd:Sender>
	<sbd:Receiver>
		<sbd:Identifier Authority="IN"/>
		<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-16T00:31:52Z</sbd:CreationDateAndTime>
	</sbd:DocumentIdentification>
	<sbd:BusinessScope>
		<sbd:Scope>
			<sbd:Type>SenderDocumentId</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>321412</sbd:Identifier>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>Country</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>IN</sbd:Identifier>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>ProcessType</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>Outbound</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>GSTInvoice</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:BusinessScope>
</sbd:StandardBusinessDocumentHeader>