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..*

Sample

<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

<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

There are additional scopes that can be informed in the Standard Business Document Header (SBDH). Each additional scope has a prefix that refers to the BusinessService. When the referred BusinessService (or Default, in case that BusinessService is part of the default flow) is being used, the additional scope information with the matching prefix can or must be informed in the SBDH.

As an example, suppose Mapping is being used as BusinessService. In that case, additional scope information must be informed using Mapping.TransformDocument and Mapping.Outschema.

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	Base-64 encoded string.	0..1	The detached signature encoded in Base-64.
Archiving.Audit.AuditData	Base-64 encoded string.	0..1	The detached audit data encoded in Base-64. If this element is omitted, no audit data exists.
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. See the Post Audit page for the possible values.
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. See the Post Audit page for more information.
Signing.SignatureFormat	Examples: PDF, XMLSIG and PKCS7	1..1	Specifies the signature format that must be applied to the invoice. See the Post Audit page for the possible values.
Signing.AuditCategory	Examples: XADESA, PADESEPES and EVIDENCE	0..1	Specifies the audit category. See the Post Audit page for the possible values.
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. See the Post Audit page for more information.
SignatureValidation.Explicit.DetachedSignature	Base-64 encoded string	0..1	If `SignatureValidation.SignatureType` is set to "Explicit", this element must be present and contain the detached signature encoded in Base-64.
SignatureValidation.Audit.AuditData	Base-64 encoded string	0..1	If `SignatureValidation.SignatureType` is set to "Audit", this element may be present. It contains the detached audit data encoded in Base-64.
SignatureValidation.SignatureFormat	Examples: PDF, XMLSIG, and PKCS7	1..1	Specifies the signature format applied to the invoice. See the Post Audit page for the possible values.
SignatureValidation.AuditCategory	Examples: XADESA, PADESEPES, and EVIDENCE	0..1	Specifies the audit category. See the Post Audit page for the possible values.
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). See the Post Audit page for the possible values.
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:

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

Sample

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