Validate a signature

The following diagram gives a detailed overview of the signature validation process for post-audit countries, based on the SignatureValidation business process.

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. To create the SBD, follow the detailed instructions in the SBDH and Sovos Document pages.

Key elements inside the SBDH:

SBDH requirementsMandatory scope informationOptional scope information

Required SBDH values:


Node	Required	Attributes	Value
StandardBusinessDocumentHeader.Sender.Identifier	Yes	Authority = An ISO 3166-1 alpha-2 country code from the country of the applicable law for the invoice.
StandardBusinessDocumentHeader.Receiver.Identifier	Yes	Authority = An ISO 3166-1 alpha-2 country code from the country of the applicable law for the invoice.
StandardBusinessDocumentHeader.DocumentIdentification.Standard	Yes		urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersion	Yes		2.1
StandardBusinessDocumentHeader.DocumentIdentification.Type	Yes		Attachment

Note:

Include all the mandatory nodes, as specified in the SBDH schema. If you cannot provide some information, and the respective mandatory node is not 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.

When validating an invoice in a post-audit scenario, you must add the following scope information in the SBDH.


Scope.Type	Required	Scope.Identifier
BusinessProcess	Yes	`BusinessProcess` doesn't have an Identifier node, so group it with the `BusinessService` node and enter "SignatureValidation".
SenderDocumentId	Yes	The sender's unique document ID, used to identify the document. While the value content is not constrained, we recommend using the unique ERP document identification.
SignatureValidation.DocumentFormat	Yes	This element specifies the format of the document you want to store. Examples: "PDF", "XML", and "CXML".
SignatureValidation.SignatureType	Yes	Enter "Implicit", "Explicit", or "Audit".
SignatureValidation.Explicit.DetachedSignature	Yes (if `SignatureValidation.SignatureType` is "Explicit")	Enter the detached Base64-encoded signature.
SignatureValidation.Audit.AuditData	No (may be present if `SignatureValidation.SignatureType` is set to "Audit")	Enter the detached audit data encoded in Base64.
SignatureValidation.SignatureFormat	Yes	This element specifies the signature format. Examples: "PDF", "XMLSIG", and "PKCS7".
SignatureValidation.AuditCategory	Yes (in some cases)	This element specifies the audit category. Examples: "XADESA", "PADESEPES", and "EVIDENCE".
SignatureValidation.ValidateFor	Yes	Enter "Sender" or "Receiver". This element specifies on behalf of which party the signed invoice should be validated.

Note:

For more information, see the About post-audit topic.

You can use this scope information for additional functionalities, such as generating new audit data.


Scope.Type	Scope.Identifier
SignatureValidation.InitialContentEncoding	This element specifies whether the initial document — the one before Sovos has applied any signature — has any additional encoding. Currently, the only supported value is "MIME", which you can use with unsigned documents to indicate that the provided content is MIME-encoded. If the value "MIME" is used with an S/MIME-signed document, this indicates that the content was already MIME-encoded before Sovos signed it. For any other document structure, you must omit this element.
SignatureValidation.NewAuditData	This element lets you create audit data. This can be the case when there is no audit data or when audit data gets promoted (for example, from CAdES-T to CAdES-A).
SignatureValidation.CreateAuditDetails	Enter "true" to include audit details in the response.
AgreeementId	An identifier string that is logged and you can use to group transactions based on, for example, different pricing models. Example: "AN-123".

Note:

For more information, see the About post-audit topic.

Below is a sample of the SBD. In addition, there's a full sample of the SBD on the Postman Samples page.

<sbd:StandardBusinessDocumentHeader>
	<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
	<sbd:Sender>
		<sbd:Identifier Authority="IN"/>
		<sbd:ContactInformation>
			<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:CommonAggregateComponents-2</sbd:Standard>
		<sbd:TypeVersion>2.1</sbd:TypeVersion>
		<sbd:InstanceIdentifier/>
		<sbd:Type>Attachment</sbd:Type>
		<sbd:MultipleType>false</sbd:MultipleType>
		<sbd:CreationDateAndTime>2020-06-12T12:00:00Z</sbd:CreationDateAndTime>
	</sbd:DocumentIdentification>
	<sbd:BusinessScope>
		<sbd:Scope>
			<sbd:Type>SenderDocumentId</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>123456789</sbd:Identifier>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>BusinessProcess</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:BusinessService>
				<sbd:BusinessServiceName>SignatureValidation</sbd:BusinessServiceName>
			</sbd:BusinessService>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>SignatureValidation.DocumentFormat</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>PDF</sbd:Identifier>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>SignatureValidation.SignatureType</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>Implicit</sbd:Identifier>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>SignatureValidation.SignatureFormat</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>PDF</sbd:Identifier>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>SignatureValidation.AuditCategory</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>PADESEPES</sbd:Identifier>
		</sbd:Scope>
		<sbd:Scope>
			<sbd:Type>SignatureValidation.ValidateFor</sbd:Type>
			<sbd:InstanceIdentifier/>
			<sbd:Identifier>Sender</sbd:Identifier>
		</sbd:Scope>
	</sbd:BusinessScope>
</sbd:StandardBusinessDocumentHeader>

Sovos Document requirements:


Node	Required	Attributes	Value
SovosDocument.SovosLegalDocument.Base64Document.EmbeddedDocument (with child nodes)	Yes	id Always enter "1" filename The name of the file mimeCode The mime type of the Base64-encoded invoice, as specified by the Internet Assigned Numbers Authority (IANA)	The string of the Base64-encoded invoice

Here is a Sovos Document sample:

<svs:SovosDocument>
  <svs:SovosLegalDocument>
    <enc:Base64Document>
      <enc:EmbeddedDocument id="1" filename="invoice.pdf" mimeCode="application/pdf">* base 64 encoded file *</enc:EmbeddedDocument>
    </enc:Base64Document>
  </svs:SovosLegalDocument>
</svs:SovosDocument>

Step 2: Buyer sends the SBD to Sovos

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

To use this endpoint, configure these request body parameters:


Name	Type	Required	Description
data	string	Yes	The SBD encoded in Base64, as created in step 1
dataEncoding	string	Yes	Always enter "base64"

Request sample

curl --location --request POST 'https://api-test-tls.sovos.com/v1/documents' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data-raw '{
	"data": "PD9...d4=",
	"dataEncoding" : "base64"
}'

Response sample

{
    "success": true,
    "status": 200,
    "message": "Process Completed",
    "timestamp": 1605183801553,
    "data": "PEF...lPg=="
}

Step 3: Sovos validates the signature

Sovos validates the signature.

Step 4: Sovos returns the validation result

As a response to the request, Indirect Tax API returns a JSON response message with an HTTP status code of 200 (synchronous transaction) and an application response that includes the validation outcome and, optionally, the validation details of the signature (SignatureValidation.CreateAuditDetails). See step 2 for a response sample.

Step 5: Archiving

As an optional step, the buyer can store the signed invoice in the compliant archive with Sovos. For more information, see the eArchiving page.

Sovos Docs

Validate a signature

Step 1: Supplier creates the Standard Business Document

Step 2: Buyer sends the SBD to Sovos

Step 3: Sovos validates the signature

Step 4: Sovos returns the validation result

Step 5: Archiving

sovos-footer