home

Indirect Tax

Sovos Docs

Show Page Sections

Israel

Enabling support for Israel involves confirming prerequisites and product IDs, registering with the Israel Tax Authority (ITA), and setting up credentials.

Prerequisites

  • An API key obtained from the ITA portal.

  • An API secret obtained from the ITA portal.

  • A refresh token obtained from the ITA portal.
    Note: Expired tokens are detected during document submission via the API. Since the refresh token expires 90 days after the first document issuance for Sandbox, be sure to get a new refresh token at that time.

Resources

Official government resources that include detailed and valuable information on various topics:

Available products

  • il_TaxInvoice__1.0

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 these pages, which include all the error codes and messages that can be returned:

Register with the Israel tax authority

Obtain the required API key, Secret, and Refresh Token by registering with the Israel Tax Authority (ITA). Follow their registration tutorial, along with the following guidance.

  • The ITA tutorial advises users to subscribe to the "Invoice Approval 1.0.0" API product after creating the app.

  • Sovos recommends subscribing to the "Longtimeacces' 1.0.0" API product.

  1. Create an Organization on the ITA portal.
    Note: The ITA tax authority's registration tutorial and portal use several terms, such as "Organization", "Apps" and "Products". These words are specific to the tax authority and are not related to Sovos concepts.
  2. Create an App.
    You'll get an API key and a Secret.
  3. Ensure both the API Key and the Secret are stored on the client side.
  4. Subscribe the app to the relevant products in the ITA portal.
  5. Perform OAuth 2.0 authentication to get the access and refresh tokens.
  6. Ensure the refresh token is stored on the client side.
    Note: The refresh token expires after 90 days, so be sure to request a new token before the old one expires.

Configure credentials for Israel

You must set up transmission credentials to connect your Sovos account to a valid business that is registered with the Israel Tax Authority (ITA).

Obtain a username, password, and signature from the ITA.
  1. Use the dedicated Create settings endpoint to add transmission credentials through the API.
  2. Complete and return an Appointment Letter to Sovos or your reseller.
  3. Complete and return a Support and Change Management Document to Sovos or your reseller.

Samples for uploading credentials for Israel

The request and response samples for uploading new credentials using the dedicated Create settings endpoint.

Request sample

Request sample for uploading new credentials:

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/organizations/YOUR-ORG-ID/settings' \
--header 'x-correlationId: developer-guide' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "context": "transmission",
        "configurations": [
            {
                "name": "partner_credentials_shaam",
                "value": {
                    "clientId": "INSERT-CLIENTID-HERE",
					"clientSecret": "INSERT-CLIENTSECRET-HERE",
					"refreshToken": "INSERT-REFRESH-TOKEN-HERE"
                },
                "scope": {
                    "category": "IL_INV",
                    "productId": "il_TaxInvoice__1.0",
                    "orgId": "YOUR-ORG-ID",
                    "taxId": "YOUR-COMPANY-TAXID"
                }
            }
        ]
    }
]'

Response sample

Response sample for uploading new credentials:

{
    "status": 201,
    "message": "Created",
    "success": true,
    "timestamp": 1666259266257,
    "data": [
        {
            "message": "Configurations are created",
            "statusCode": 201,
            "configurationContextResponse": {
                "context": "Transmission",
                "configurations": [
                    {
                        "id": "SETTING-ID",
                        "name": "partner_credentials_shaam",
                        "value": {
                            "clientId": "INSERT-CLIENTID-HERE",
					        "clientSecret": "INSERT-CLIENTSECRET-HERE",
					        "refreshToken": "INSERT-REFRESH-TOKEN-HERE"
                        },
                        "scope": {
                            "category": "IL_INV",
                            "productId": "il_TaxInvoice__1.0",
                            "orgId": "YOUR-ORG-ID",
                            "taxId": "YOUR-COMPANY-TAXID"
                        },
                        "auditData": {
                            "createdAt": 1666259265,
                            "createdBy": "user@company.com",
                            "isDeleted": false,
                            "version": 1
                        }
                    }
                ]
            }
        }
    ]
}

Issue invoice

Issuing invoices in Israel is based on the Default business process, which follows this order: Mapping and Transmission. The following diagram provides a detailed overview:

Israel outbound flow

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

Here are some key elements that should be included in the SBD and in the invoice:

Use the following values in the SBDH for documents that use the SCI format:

NodeRequiredAttributesValue
StandardBusinessDocumentHeader.Sender.IdentifierYesAuthority="IL"Supplier's TIN
StandardBusinessDocumentHeader.Receiver.IdentifierYesAuthority="IL"
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: IL

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

Child node Identifier : Supplier's TIN

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. If SenderSystemId is not configured on the client side, it will use the default value of "DefaultSystemERP". For more information, see this topic.

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.OutputSchema

Child node Identifier : TaxInvoice

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: SCI-TO-LEGAL_INVOICE

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)YesChild node Type: SubSchema
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: BusinessCategory

Child node Identifier: B2B

StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type : Version

Child node Identifier: 1.0

StandardBusinessDocumentHeader.BusinessScope.Scope.BusinessService.BusinessServiceNameYesDefault
SovosDocument.SovosCanonicalInvoice.InvoiceYesSCI

Alternatively, the supplier can use the local format (JSON) instead of SCI. Use the following values in the SBDH for documents that use the local format:

NodeRequiredValue
StandardBusinessDocumentHeader.DocumentIdentification.StandardYesILInvoice
StandardBusinessDocumentHeader.DocumentIdentification.TypeVersionYes1.0
StandardBusinessDocumentHeader.DocumentIdentification.TypeYesInvoice
StandardBusinessDocumentHeader.BusinessScope.Scope (with child nodes)Yes

Child node Type: Mapping.TransformDocument

Child node Identifier: LEGAL-TO-SCI_INVOICE

SovosDocument.SovosLegalDocument.Base64DocumentYesA local format

You need to encode the local format (JSON) document in Base64 before you can add it as part of the SBD. Here is a sample:

    </sbd:StandardBusinessDocumentHeader>
    <svs:SovosDocument>
        <svs:SovosLegalDocument>
            <enc:Base64Document>
                <enc:EmbeddedDocument mimeCode="application/json">eyJJbnZvaW...OjUuOHldfQ==</enc:EmbeddedDocument>
            </enc:Base64Document>
        </svs:SovosLegalDocument>
    </svs:SovosDocument>
</svs:StandardBusinessDocument>

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

  • Invoice/Transaction Invoice (300)

  • Tax Invoice (305)

  • Tax Invoice I [for future use] (306)

  • Periodic Tax invoice (310)

  • Tax invoice/receipt (320)

  • Credit tax invoice (330)

  • Credit tax invoice I [for future use] (331)

  • Pro forma invoice (332)

Note:

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

SBD sample
Below is a sample of the SBD. In addition, there's a full sample of the SBD on 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:sbd="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" 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" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2">
	<sbd:StandardBusinessDocumentHeader>
		<sbd:HeaderVersion>1.0</sbd:HeaderVersion>
		<sbd:Sender>
			<sbd:Identifier Authority="IL">777777715</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="IL"/>
			<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>Version</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>1.0</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderDocumentId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>321412</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SenderSystemId</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>UAT101</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
                <sbd:Type>CompanyCode</sbd:Type>
                <sbd:InstanceIdentifier/>
                <sbd:Identifier>08AAACI9260R002</sbd:Identifier>
            </sbd:Scope>
			<sbd:Scope>
				<sbd:Type>Country</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>IL</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>TaxInvoice</sbd:Identifier>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>SubSchema</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier/>
			</sbd:Scope>
			<sbd:Scope>
				<sbd:Type>BusinessCategory</sbd:Type>
				<sbd:InstanceIdentifier/>
				<sbd:Identifier>B2B</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>
	<svs:SovosDocument>
		<sci:SovosCanonicalInvoice>
			<inv:Invoice>
			    *UBL Elements*
			</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.

The request must include the following request body parameters:

NameTypeRequiredDescription
datastringYesThe SBD encoded in Base64, as created in step 1.
dataEncodingstringYesEnter "base64".

After receiving the document, Sovos performs a structure/schema validation of both the SCI and the SBD parts.

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
{
    "timestamp": 1605282724079,
    "status": 202,
    "success": true,
    "message": "Document Received",
    "data": {
        "documentId": "3add2b7104dc0049ff0bf410f57e0a19afaf"
    }
}

Step 3: Sovos maps the SCI into JSON

Upon receiving the SCI, Sovos maps the file into the required JSON format.
Note:

This step will be skipped if the SBD contains the invoice in the local format (JSON).

Step 4: Sovos performs the schema validation

Sovos performs a schema validation based on the information provided by the tax authority. If there are errors in the document, Sovos detects them instead of waiting for the tax authority's response.

Step 5: Sovos transmits the JSON

Sovos transmits the JSON file to the ITA tax authority.

Step 6: ITA processes the JSON

ITA performs a schema validation and several business validations. Then it generates an approval or rejection response message along with an error message, where applicable. Upon approval, ITA also assigns an Allocation Number.

Step 7: ITA sends the response to Sovos

After performing its services, ITA sends the response to Sovos.

Step 8: Supplier retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a 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 the cleared JSON encoded in Base64 after it's available during the process.

Options for retrieving application responses (notifications):

Fetch everything in one single response (notification)
When polling for responses, Sovos only returns one final notification with SCICloudStatusCode of 209 that contains all the relevant attachments and data. Detailed description follows.
Fetch multiple responses (notifications) containing different information
When polling for responses, Sovos returns multiple notifications with different SCICloudStatusCode values containing different attachments and data until the final one (with status 209) is returned. Detailed description follows.
Note:

To configure notifications for your company or update your current configuration, contact the Professional Services team.

To complete a transaction, the supplier retrieves only one notification, the complete workflow one, with SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, the notification needs to be parsed for the SCIResponseCode value. Possible values for SCIResponseCode:

AP
The document's compliance status has been accepted with all the necessary attachments and data included.
RE
The document's compliance status has been rejected, and more parsing is needed:
  • If SCIGovtStatusCode is present, the error can be found by reading StatusReason.

  • if SCIInternalValidationCode is present, the error can be found by reading StatusReason.

Note: Receiving a notification containing SCICloudStatusCode with a value in the 5xx range still remains an option, as it indicates a server error. In this case, the workflow doesn't finish in the sense that it doesn't return a notification with SCICloudStatusCode of 209.
#SCICloudStatusCode SCIResponseCode Sample
1 209AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed
2209RE
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIGovtStatusCode">432</cbc:StatusReasonCode>
        <cbc:StatusReason>Param: Customer_VAT_Number, Message: Customer VAT Number is incorrect</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed

To complete a transaction, the supplier must retrieve the application responses until the transaction has finished. If the supplier has subscribed to all notifications, the transaction can generate different application responses. See the table below:

#SCICloudStatusCodeSCIResponseCode Sample
1100IP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">100</cbc:StatusReasonCode>
				<cbc:StatusReason>Document received successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">100-Received successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Document received successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document received successfully
2101IP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">101</cbc:StatusReasonCode>
				<cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode"/>
				<cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document mapped successfully
3200AP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">200</cbc:StatusReasonCode>
				<cbc:StatusReason>Authorized by the tax authority</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">200-Authorized</cbc:StatusReasonCode>
				<cbc:StatusReason>Authorized by the tax authority</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Authorized by the tax authority
4209IP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed
5400RE
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">400</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
				<cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">400-Rejected</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">434</cbc:StatusReasonCode>
				<cbc:StatusReason>Param: Invoice_Date, Message: Invoice date is more than two weeks old</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Rejected by the tax authority or the counterparty
6400RE
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">400</cbc:StatusReasonCode>
        <cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
        <cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">400-Rejected</cbc:StatusReasonCode>
        <cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIGovtStatusCode">460</cbc:StatusReasonCode>
        <cbc:StatusReason>Param: approval, Message: Invoice not approved</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Rejected by the tax authority or the counterparty - Document not approved
7400RE
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">400</cbc:StatusReasonCode>
        <cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
        <cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">400-Rejected</cbc:StatusReasonCode>
        <cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIGovtStatusCode">461</cbc:StatusReasonCode>
        <cbc:StatusReason>Param: approval, Message: The unapproved invoice exists.No decision was sent</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Rejected by the tax authority or the counterparty - Decision not sent
8400RE
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">400</cbc:StatusReasonCode>
        <cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
        <cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">400-Rejected</cbc:StatusReasonCode>
        <cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIGovtStatusCode">462</cbc:StatusReasonCode>
        <cbc:StatusReason>Param: approval, Message: The unapproved invoice exists and decision was sent</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Rejected by the tax authority or the counterparty - Decision already sent
9401RE
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">401</cbc:StatusReasonCode>
				<cbc:StatusReason>Error processing document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
				<cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">401-Document error</cbc:StatusReasonCode>
				<cbc:StatusReason>Error processing document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIInternalValidationStatusCode">401</cbc:StatusReasonCode>
				<cbc:StatusReason>Required properties are missing from object: Amount_Before_Discount, Discount, Payment_Amount, VAT_Amount, Items. Path '', line 1, position 1.</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Error processing document

The supplier can use the following Indirect Tax API endpoints to retrieve application responses:

  • GET /notifications/IL

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

GET /notifications/IL
The supplier can send a GET request to the /notifications/IL endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNo

Include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.

Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the sourceSystemId parameter.

pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

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

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

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications, within 24 hours of their acknowledgment, must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/IL?page=1&perPage=2&includeAcknowledged=true&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "status": 200,
    "message": "Notifications Listed",
    "success": true,
    "timestamp": 1697121108142,
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 20,
            "totalEntries": 1,
            "totalPages": 1
        },
        "notifications": [
            {
                "notificationId": "ec528863-a8f4-496c-82c9-da169318a928",
                "correlationId": "01b3c8bf-a04f-4ade-af79-3ea8f1613b39-mock",
                "appPrefix": "DLT",
                "metadata": {
                    "productId": "il_TaxInvoice__1.0",
                    "transactionId": "f88b9986-d98b-41e1-8202-0139dc1a5cb4",
                    "documentId": "f59b6e91d5789a97ecf5c1c720aed9d7",
                    "erpDocumentId": "77406967",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "777777715",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "Success"
                },
                "content": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu...FwcGxpY2F0aW9uUmVzcG9uc2U+",
                "createdDate": 1697121090735
            }
        ]
    }
}
GET /documents/IL/{documentId}/notifications
The supplier can send a GET request to the /documents/IL/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameter:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 2
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/IL/{documentId}/notifications?' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
{
    "status": 200,
    "message": "Notifications Listed",
    "success": true,
    "timestamp": 1697121108142,
    "data": {
        "pageState": {
            "page": 1,
            "perPage": 20,
            "totalEntries": 1,
            "totalPages": 1
        },
        "notifications": [
            {
                "notificationId": "ec528863-a8f4-496c-82c9-da169318a928",
                "correlationId": "01b3c8bf-a04f-4ade-af79-3ea8f1613b39-mock",
                "appPrefix": "DLT",
                "metadata": {
                    "productId": "il_TaxInvoice__1.0",
                    "transactionId": "f88b9986-d98b-41e1-8202-0139dc1a5cb4",
                    "documentId": "f59b6e91d5789a97ecf5c1c720aed9d7",
                    "erpDocumentId": "77406967",
                    "erpSystemId": "UAT101",
                    "processType": "0",
                    "taxId": "777777715",
                    "sciCloudStatusCode": "200",
                    "sciResponseCode": "AP",
                    "sciStatusAction": "NOA",
                    "sciGovtStatusCode": "Success"
                },
                "content": "PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGlu...FwcGxpY2F0aW9uUmVzcG9uc2U+",
                "createdDate": 1697121090735
            }
        ]
    }
}

Step 9: Supplier marks the application responses as acknowledged

The supplier must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/IL endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in 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/IL' \
--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."
}

Step 10: Archiving

You can compliantly archive the JSON, the application response, and any graphical representation, such as a PDF, using Sovos' Compliant Archive.

For suppliers integrating with the Sovos solution for Israel for the first time, we recommend the bundled approach, in which archiving is part of the invoice clearance flow. Archiving can also be done separately through an explicit API call that uses another archive. For more information on standalone archiving, see the eArchiving documentation page.

Note: Bundled e-invoice archiving is optional. This means you can use your current solution and include Sovos e-Archiving.

Step 11: Supplier sends the invoice to the buyer

The invoice should be sent to the buyer along with the Allocation Number, as they need it to look up the invoice data on the ITA system.

Note: When transmitting an invoice, it's important to keep the invoice's authenticity and integrity. See our Post-audit Signing and Validation service for more information on how to sign electronic documents in Israel.

Cancel invoice

With the recent changes in the Israel Mandate, the ITA will now have the ability to hold invoices. This means not all invoices will be immediately approved or rejected. Now they can be in a "held" state where the issuer is required to submit a "decision" on what is to be done next with the contested document.

The "decision" can be in the form of:

  • Reverse charge (which is not the point of discussion for this document)

  • Document action: "Cancellation", "Continue", and "Request for a hearing"

The following diagram provides a detailed overview:

Israel invoice cancellation flow

Step 1: Buyer sends a POST request to Sovos

When the buyer wants to cancel an invoice in Israel, they send a POST request to the /documents/IL/action endpoint. To make this request, set the following request body parameters:

NameTypeRequiredDescription
actionCodestringYes Always enter "document.cancellation".
documentsarray of objectsYesAn array of objects to include the metadata and the inbound document ID.
documentIdstringYesThe ID of the document to be handled. This is the documentId Sovos returns when receiving the document.
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents/IL/action' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '{
  "actionCode": "document.cancellation",
  "documents": [
    {
      "documentId": "70a...89a0"
    }
  ]
}
Response sample
{
	"status": 202,
	"message": "Accepted",
	"success": true,
	"timestamp": 1724404345626
	"data":[
		{
			"status": 202,
			"transactionId": "564c4995-...-4a3976feb6ea",
			"documentId": "70a...89a0"
		}
	]
}

Step 2: Sovos transmits the request to ITA

Sovos finds the corresponding document in the system and transmits the decision request to ITA.

Step 3: ITA processes the request

ITA verifies that the decision can be processed.

Step 4: ITA returns the response

ITA returns the success message or, if the action could not be performed, it returns an error message.

Step 5: Buyer retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial request, the client receives a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the buyer must retrieve the application responses that become available during the transaction, which provide status information.

Options for retrieving application responses (notifications):

Fetch everything in one single response (notification)
When polling for responses, Sovos only returns one final notification with SCICloudStatusCode of 209 that contains all the relevant attachments and data. Detailed description follows.
Fetch multiple responses (notifications) containing different information
When polling for responses, Sovos returns multiple notifications with different SCICloudStatusCode values containing different attachments and data until the final one (with status 209) is returned. Detailed description follows.

To complete a transaction, the buyer retrieves only one notification, the complete workflow one, with SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, the notification needs to be parsed for the SCIResponseCode value. Possible values for SCIResponseCode:

AP
The document's compliance status has been accepted with all the necessary attachments and data included.
RE
The document's compliance status has been rejected, and more parsing is needed:
  • If SCIGovtStatusCode is present, the error can be found by reading StatusReason.

  • if SCIInternalValidationCode is present, the error can be found by reading StatusReason.

Note: Receiving a notification containing SCICloudStatusCode with a value in the 5xx range still remains an option, as it indicates a server error. In this case, the workflow doesn't finish in the sense that it doesn't return a notification with SCICloudStatusCode of 209.
#SCICloudStatusCode SCIResponseCode Sample
1 209AP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed
2209CA
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">461</cbc:StatusReasonCode>
				<cbc:StatusReason>Param: approval, Message: The unapproved invoice exists.No decision was sent</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed

To complete a transaction, the buyer must retrieve the application responses until the transaction has finished. If the supplier has subscribed to multiple notifications, the transaction can generate different application responses, as shown in the table below. The transaction finishes when a notification containing SCICloudStatusCode with the value of 209 has been received.

#SCICloudStatusCodeSCIResponseCode Sample
1100IP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">100</cbc:StatusReasonCode>
				<cbc:StatusReason>Document received successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">100-Received successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Document received successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document received successfully
2101IP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">101</cbc:StatusReasonCode>
				<cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode"/>
				<cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Document mapped successfully
3201AP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">201</cbc:StatusReasonCode>
				<cbc:StatusReason>Cancelled</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">201-Cancelled successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Cancelled</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Cancelled
4209AP
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
				<cbc:StatusReason>No action required</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
				<cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Workflow Successfully Completed
5400RE
	<cac:DocumentResponse>
		<cac:Response>
			<cbc:ReferenceID/>
			<cbc:ResponseCode listID="SCIResponseCode">RE</cbc:ResponseCode>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCICloudStatusCode">400</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIStatusAction">NIN</cbc:StatusReasonCode>
				<cbc:StatusReason>Request to re-issue a corrected new invoice (or other document) or fix the error and resend the document</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIERPStatusCode">400-Rejected</cbc:StatusReasonCode>
				<cbc:StatusReason>Rejected by the tax authority or the counter party</cbc:StatusReason>
			</cac:Status>
			<cac:Status>
				<cbc:StatusReasonCode listID="SCIGovtStatusCode">461</cbc:StatusReasonCode>
				<cbc:StatusReason>Param: approval, Message: The unapproved invoice exists.No decision was sent</cbc:StatusReason>
			</cac:Status>
		</cac:Response>
Rejected by the tax authority or the counter party

The buyer can use the following Indirect Tax API endpoints to retrieve application responses:

  • GET /notifications/IL

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

GET /notifications/IL
The buyer can send a GET request to the /notifications/IL endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNo

Include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.

Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the sourceSystemId parameter.

pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

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

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

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/IL?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' 
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "78bd5a18-...-73bfbdb3bf21",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "il_TaxInvoice__1.0",
                "transactionId": "43...d94",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "192714478",
                "erpSystemId": "ERPSystem",
                "processType": "1",
                "taxId": "C873686030",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255
GET /documents/IL/{documentId}/notifications
The buyer can send a GET request to the /documents/IL/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameters:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 1
includeAcknowledgedboolean NoQueryfalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/IL/{documentId}/notifications?includeAcknowledged=false' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN'\
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "78bd5a18-...-73bfbdb3bf21",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "il_TaxInvoice__1.0",
                "transactionId": "43...d94",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "192714478",
                "erpSystemId": "ERPSystem",
                "processType": "1",
                "taxId": "C873686030",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255

Step 6: Buyer marks the application responses as acknowledged

The buyer must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/IL endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in 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/IL' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '[
    {
        "status": "read",
        "notificationId": "e7b32eda-...-f6d9c90f60d9"
    }
]'
Response sample
{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1708509282198,
    "data": {}
}

Continue invoice

With the recent changes in the Israel Mandate, the ITA will now have the ability to hold invoices. This means not all invoices will be immediately approved or rejected. Now they can be in a "held" state where the issuer is required to submit a "decision" on what is to be done next with the contested document.

The "decision" can be in the form of:

  • Reverse charge (which is not the point of discussion for this document)

  • Document action: "Cancellation", "Continue", and "Request for a hearing"

The following diagram provides a detailed overview:

Israel invoice continue flow

Step 1: Buyer sends a POST request to Sovos

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

NameTypeRequiredDescription
actionCodestringYes Always enter "document.continue".
documentsarray of objectsYesAn array of objects to include the metadata and the inbound document ID.
documentIdstringYesThe ID of the document to be handled. This is the documentId Sovos returns when receiving the document.
Request sample
curl --location  --request POST 'https://api-test.sovos.com/v1/documents/IL/action' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '{
  "actionCode": "document.continue",
  "documents": [
    {
      "documentId": "70a...89a0"
    }
  ]
}
Response sample
{
	"status": 202,
	"message": "Accepted",
	"success": true,
	"timestamp": 1724404345626
	"data":[
		{
			"status": 202,
			"transactionId": "564c4995-...-4a3976feb6ea",
			"documentId": "70a...89a0"
		}
	]
}

Step 2: Sovos transmits the request to ITA

Sovos finds the corresponding document in the system and transmits the decision request to ITA.

Step 3: ITA processes the request

ITA verifies that the decision can be processed.

Step 4: ITA returns the response

ITA returns the success message or, if the action could not be performed, it returns an error message.

Step 5: Buyer retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial request, the client receives a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the buyer must retrieve the application responses that become available during the transaction, which provide status information.

Options for retrieving application responses (notifications):

Fetch everything in one single response (notification)
When polling for responses, Sovos only returns one final notification with SCICloudStatusCode of 209 that contains all the relevant attachments and data. Detailed description follows.
Fetch multiple responses (notifications) containing different information
When polling for responses, Sovos returns multiple notifications with different SCICloudStatusCode values containing different attachments and data until the final one (with status 209) is returned. Detailed description follows.

To complete a transaction, the buyer retrieves only one notification, the complete workflow one, with SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, the notification needs to be parsed for the SCIResponseCode value. Possible values for SCIResponseCode:

AP
The document's compliance status has been accepted with all the necessary attachments and data included.
RE
The document's compliance status has been rejected, and more parsing is needed:
  • If SCIGovtStatusCode is present, the error can be found by reading StatusReason.

  • if SCIInternalValidationCode is present, the error can be found by reading StatusReason.

Note: Receiving a notification containing SCICloudStatusCode with a value in the 5xx range still remains an option, as it indicates a server error. In this case, the workflow doesn't finish in the sense that it doesn't return a notification with SCICloudStatusCode of 209.
#SCICloudStatusCode SCIResponseCode Sample
1 209AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed

To complete a transaction, the buyer must retrieve the application responses until the transaction has finished. If the supplier has subscribed to multiple notifications, the transaction can generate different application responses, as shown in the table below. The transaction finishes when a notification containing SCICloudStatusCode with the value of 209 has been received.

#SCICloudStatusCodeSCIResponseCode Sample
1100IP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">100</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">100-Received successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document received successfully
2101IP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">101</cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode"></cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document mapped successfully
3213AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">213</cbc:StatusReasonCode>
        <cbc:StatusReason>Continued</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">213-Continued successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Continued</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Continue decision accepted
4209AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed

The buyer can use the following Indirect Tax API endpoints to retrieve application responses:

  • GET /notifications/IL

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

GET /notifications/IL
The buyer can send a GET request to the /notifications/IL endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNo

Include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.

Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the sourceSystemId parameter.

pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

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

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

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/IL?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "78bd5a18-...-73bfbdb3bf21",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "il_TaxInvoice__1.0",
                "transactionId": "43...d94",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "192714478",
                "erpSystemId": "ERPSystem",
                "processType": "1",
                "taxId": "C873686030",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255
GET /documents/IL/{documentId}/notifications
The buyer can send a GET request to the /documents/IL/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameter:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 1
includeAcknowledgedboolean NoQueryfalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/IL/{documentId}/notifications?includeAcknowledged=false' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "78bd5a18-...-73bfbdb3bf21",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "il_TaxInvoice__1.0",
                "transactionId": "43...d94",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "192714478",
                "erpSystemId": "ERPSystem",
                "processType": "1",
                "taxId": "C873686030",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255

Step 6: Buyer marks the application responses as acknowledged

The buyer must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/IL endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in 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/IL' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '[
    {
        "status": "read",
        "notificationId": "e7b32eda-...-f6d9c90f60d9"
    }
]'
Response sample
{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1708509282198,
    "data": {}
}

Request invoice hearing

With the recent changes in the Israel Mandate, the ITA will now have the ability to hold invoices. This means not all invoices will be immediately approved or rejected. Now they can be in a "held" state where the issuer is required to submit a "decision" on what is to be done next with the contested document.

The "decision" can be in the form of:

  • Reverse charge (which is not the point of discussion for this document)

  • Document action: "Cancellation", "Continue", and "Request for a hearing"

The following diagram provides a detailed overview:

Israel invoice request for hearing flow

Step 1: Buyer sends a POST request to Sovos

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

NameTypeRequiredDescription
actionCodestringYes Always enter "document.hearingRequest" .
documentsarray of objectsYesAn array of objects to include the metadata and the inbound document ID.
documentIdstringYesThe ID of the document to be handled. This is the documentId Sovos returns when receiving the document.
Request sample
curl --location --request POST 'https://api-test.sovos.com/v1/documents/IL/action' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--data '{
  "actionCode": "document.hearingRequest",
  "documents": [
    {
      "documentId": "70a...89a0"
    }
  ]
}
Response sample
{
	"status": 202,
	"message": "Accepted",
	"success": true,
	"timestamp": 1724404345626
	"data":[
		{
			"status": 202,
			"transactionId": "564c4995-...-4a3976feb6ea",
			"documentId": "70a...89a0"
		}
	]
}

Step 2: Sovos transmits the request to ITA

Sovos finds the corresponding document in the system and transmits the decision request to ITA.

Step 3: ITA processes the request

ITA verifies that the decision can be processed.

Step 4: ITA returns the response

ITA returns the success message or, if the action could not be performed, it returns an error message.

Step 5: Buyer retrieves the application responses

Attachments configuration
Sovos highly recommends configuring your 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".
Note:

When you use "download links", the response contains a URL to download the file. When you use "binary data", the file is embedded in the base64-encoded response. This configuration is available through the Professional Services team.

As a response to the initial request, the client receives a JSON response message with an HTTP status code of 202 (asynchronous transaction). This means that the buyer must retrieve the application responses that become available during the transaction, which provide status information.

Options for retrieving application responses (notifications):

Fetch everything in one single response (notification)
When polling for responses, Sovos only returns one final notification with SCICloudStatusCode of 209 that contains all the relevant attachments and data. Detailed description follows.
Fetch multiple responses (notifications) containing different information
When polling for responses, Sovos returns multiple notifications with different SCICloudStatusCode values containing different attachments and data until the final one (with status 209) is returned. Detailed description follows.

To complete a transaction, the buyer retrieves only one notification, the complete workflow one, with SCICloudStatusCode of 209 and all the necessary attachments and data. Afterwards, the notification needs to be parsed for the SCIResponseCode value. Possible values for SCIResponseCode:

AP
The document's compliance status has been accepted with all the necessary attachments and data included.
RE
The document's compliance status has been rejected, and more parsing is needed:
  • If SCIGovtStatusCode is present, the error can be found by reading StatusReason.

  • if SCIInternalValidationCode is present, the error can be found by reading StatusReason.

Note: Receiving a notification containing SCICloudStatusCode with a value in the 5xx range still remains an option, as it indicates a server error. In this case, the workflow doesn't finish in the sense that it doesn't return a notification with SCICloudStatusCode of 209.
#SCICloudStatusCode SCIResponseCode Sample
1 209AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed

To complete a transaction, the buyer must retrieve the application responses until the transaction has finished. If the supplier has subscribed to multiple notifications, the transaction can generate different application responses, as shown in the table below. The transaction finishes when a notification containing SCICloudStatusCode with the value of 209 has been received.

#SCICloudStatusCodeSCIResponseCode Sample
1100IP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">100</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">100-Received successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Document received successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document received successfully
2101IP
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">IP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">101</cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode"></cbc:StatusReasonCode>
        <cbc:StatusReason>Document mapped successfully</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Document mapped successfully
3214AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">214</cbc:StatusReasonCode>
        <cbc:StatusReason>HearingRequested</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">214-Hearing Requested successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>HearingRequested</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Request hearing accepted
4209AP
  <cac:DocumentResponse>
    <cac:Response>
      <cbc:ReferenceID></cbc:ReferenceID>
      <cbc:ResponseCode listID="SCIResponseCode">AP</cbc:ResponseCode>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCICloudStatusCode">209</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIStatusAction">NOA</cbc:StatusReasonCode>
        <cbc:StatusReason>No action required</cbc:StatusReason>
      </cac:Status>
      <cac:Status>
        <cbc:StatusReasonCode listID="SCIERPStatusCode">209-Completed successfully</cbc:StatusReasonCode>
        <cbc:StatusReason>Workflow Successfully Completed</cbc:StatusReason>
      </cac:Status>
    </cac:Response>
Workflow Successfully Completed

The buyer can use the following Indirect Tax API endpoints to retrieve application responses:

  • GET /notifications/IL

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

GET /notifications/IL
The buyer can send a GET request to the /notifications/IL endpoint to retrieve application responses that match the configured search criteria. To make this request, set the following query parameters:
NameTypeRequiredDefaultDescription
taxIdstringNo

Include only notifications related to the specified taxId. This value relates to the CompanyCode set in the SBDH.

Note: If a request doesn't include this parameter, it will return all the notifications related to the country and the sourceSystemId parameter.

pageintegerNo1To specify the page to be returned, enter a value between 1 and 10.
perPageintegerNo10

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

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

sourceSystemIdstringYesInclude only notifications related to documents that originate from the given source system. This value is related to the SenderSystemId in the SBDH.
includeAcknowledgedbooleanNofalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
processTypestringNoEnter "0" to only include notifications related to outbound documents.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/notifications/IL?page=1&perPage=2&taxId={taxId}&sourceSystemId={sourceSystemId}&processType=0' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' 
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "78bd5a18-...-73bfbdb3bf21",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "il_TaxInvoice__1.0",
                "transactionId": "43...d94",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "192714478",
                "erpSystemId": "ERPSystem",
                "processType": "1",
                "taxId": "C873686030",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255
GET /documents/IL/{documentId}/notifications
The buyer can send a GET request to the /documents/IL/{documentId}/notifications endpoint to retrieve application responses related to a single document. To make this request, set the following parameter:
NameTypeRequiredParameter typeDefaultDescription
documentIdstringYesPathThe ID of the document returned in step 1
includeAcknowledgedboolean NoQueryfalseEnter "true" to specify whether previously acknowledged notifications must be included in the result.
Request sample
curl --location --request GET 'https://api-test.sovos.com/v1/documents/IL/DOCUMENT-ID/notifications?includeAcknowledged=false' \
--header 'Content-Type: application/json' \
--header 'Authorization: Bearer TOKEN'\
--header 'x-correlationId: SET-TO-UNIQUE-VALUE'
Response sample
"status": 200,
"message": "Notifications Listed",
"success": true,
"timestamp": 1708533734893,
"data": {
    "pageState": {
        "page": 1,
        "perPage": 20,
        "totalEntries": 52,
        "totalPages": 3
    },
    "notifications": [
        {
            "notificationId": "78bd5a18-...-73bfbdb3bf21",
            "correlationId": "SET-TO-UNIQUE-VALUE",
            "appPrefix": "DLT",
            "metadata": {
                "productId": "il_TaxInvoice__1.0",
                "transactionId": "43...d94",
                "documentId": "DOCUMENT-ID",
                "erpDocumentId": "192714478",
                "erpSystemId": "ERPSystem",
                "processType": "1",
                "taxId": "C873686030",
                "sciCloudStatusCode": "209",
                "sciResponseCode": "AP",
                "sciStatusAction": "NOA",
                "sciGovtStatusCode": "Success"
            },
            "content": "PD...2U+",
            "createdDate": 1708533707255

Step 6: Buyer marks the application responses as acknowledged

The buyer must process the retrieved application responses and mark them as acknowledged. This can be done by sending a PUT request to the /notifications/IL endpoint.

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

NameTypeRequiredDescription
statusstringYesEnter "read".
notificationIdstringYesThe ID of the notification that must be marked as acknowledged.
Note: Multiple notificationId values can be acknowledged in 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/IL' \
--header 'Content-Type: application/json' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Authorization: Bearer TOKEN' \
--data '[
    {
        "status": "read",
        "notificationId": "e7b32eda-...-f6d9c90f60d9"
    }
]'
Response sample
{
    "status": 200,
    "message": "OK",
    "success": true,
    "timestamp": 1708509282198,
    "data": {}
}

Mock tax authority integration

You can test the integration with the Sovos solution for Israel using a mocked tax authority communication. For that, you can use Sovos' mocked services, which replace the tax authority communication in the solution and let you make limited tests of business scenarios.

You can also dynamically distinguish between mocked services and testing against the real tax authority UAT environment on a document-by-document basis.

Testing with Sovos’ mocked services is not a replacement for the UAT/Sandbox environment tests. With that in mind, you should keep making tests in the UAT/Sandbox environment before moving to the Production environment. This is because Sovos’ mocked services cannot fully simulate the tax authority behavior and validations due to the vast amount of different business scenarios that are applicable to Israel.

Outbound Mock

The Outbound Mock simulates sending documents to the tax authority. Before issuing your documents, you must upload specific credentials using the Configurations v2 API resource.
Outbound Mock configuration
To use the mock services for Israel Outbound, you need to configure these specific credentials (inside the value object) using the POST /v2/configurations/organizations/{organizationId}/settings endpoint from Configurations v2:
clientId
cc21dfbcfc31f5c0b572906061b640d1
clientSecret
9a92640a971ff1267413747661d2f8b5
refreshToken
AAJMoDuzFkpMpHfFYN8yK_YnlOdPxiBBXdovFBdsbAQVnf68wHvQUYYDr6x0uHpjEK0n2Mg2pBQX8-dxpoTHtYkzuZk9bcgQd5nnAZepUEq8bQ

Here is a sample request using these credentials:

curl --location --request POST 'https://api-test.sovos.com/v2/configurations/organizations/YOUR-ORG-ID/settings' \
--header 'x-correlationId: developer-guide-mock' \
--header 'Content-Type: application/json' \
--data-raw '[
    {
        "context": "transmission",
        "configurations": [
            {
                "name": "partner_credentials_shaam",
                "value": {
                    "clientId": "cc21dfbcfc31f5c0b572906061b640d1",
					"clientSecret": "9a92640a971ff1267413747661d2f8b5",
					"refreshToken": "AAJMoDuzFkpMpHfFYN8yK_YnlOdPxiBBXdovFBdsbAQVnf68wHvQUYYDr6x0uHpjEK0n2Mg2pBQX8-dxpoTHtYkzuZk9bcgQd5nnAZepUEq8bQ"
                },
                "scope": {
                    "category": "IL_INV",
                    "productId": "il_TaxInvoice__1.0",
                    "orgId": "YOUR-ORG-ID",
                    "taxId": "YOUR-COMPANY-TAXID"
                }
            }
        ]
    }
]'
Outbound Mock usage

When sending a document with the POST /v1/documents endpoint to reach the mocked services, the x-correlationId value must end with "-mock". For example, x-correlationId = "123-mock". Sovos' solution distinguishes between the mocked Outbound services and the real tax authority UAT environment based on the presence of this value.

When using the GET method with the Notifications endpoints, the x-correlationId doesn't need to end with "-mock". This is because the Sovos solution doesn't differentiate between mocked notifications and notifications related to the real tax authority UAT environment — they are both treated as "notifications", which can be retrieved normally. The same reasoning applies to marking notifications as acknowledged with the PUT method: there's no need to add an x-correlationId ending with "-mock".

To test Outbound against the real tax authority UAT environment, it is crucial to follow the correct prerequisites and configuration steps. This involves obtaining the real tax authority credentials and configuring them in the Sovos solution. So, when issuing the document, make sure that x-correlationId doesn't end with "-mock".

The mock services also support testing the requirements related to held documents. For the mock services to reject a document holding it, you need to enter "not-approved" in the invoice_reference_number field. After receiving the rejection, you can then request any of the possible actions:

  • Cancellation

  • Continue

  • Request hearing

  • Reverse charge (calling the POST /documents endpoint again with "VAT_Amount" and "Vat_Rate" set to 0, and the action parameter set to 3).

You can also simulate the errors that ITA returns if you request one of the three actions for a previously sent document or request the same action twice for the same document. In those cases, you will receive an HTTP 400 (Bad Request) error from the Platform with the following message: "Precondition failed".

Outbound Mock validation

The main purpose of the mocked services is to let you test the end-to-end flow early in the integration process, without being blocked by the need for real tax authority credentials. You can only test a limited set of scenarios based on the document's content:

invoice_date
The invoice date should be less than two weeks old.
invoice_id
The length of the value should be 1-30.
items.category
The first character should be "1" or "2".
items.price_per_unit
It should be a numeric value of the decimal type, with no more than four digits after the number.
items.total_amount
It should be a numeric value of the decimal type, with no more than two digits after the number.
items.vat_amount
It should be a numeric value of the decimal type, with no more than two digits after the number.
customer_vat_number
It should be either 777777715 or 18.
vat_number
The value should be less than or equal to 999999999.
Required field missing
Example: vat_number.

Payload samples

Sovos Canonical Invoice (SCI)

The provided SCI and Local XML samples are meant to be guidelines for integration with the Indirect Tax API and should be treated as such, since each integrating system is unique and has different requirements. This means that the samples cannot be copied directly, and must be adapted to your system when integrating with the Indirect Tax API.

Invoice data sample for a domestic B2B transaction:

<?xml version="1.0" encoding="UTF-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:n0="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:crn="urn:oasis:names:specification:ubl:schema:xsd:CreditNote-2" xmlns:dbn="urn:oasis:names:specification:ubl:schema:xsd:DebitNote-2" xmlns:enc="http://www.sovos.com/namespaces/base64Document" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:inv="urn:oasis:names:specification:ubl:schema:xsd:Invoice-2" xmlns:qdt="urn:oasis:names:specification:ubl:schema:xsd:QualifiedDataTypes-2" xmlns:sac="urn:oasis:names:specification:ubl:schema:xsd:SignatureAggregateComponents-2" xmlns:sbc="urn:oasis:names:specification:ubl:schema:xsd:SignatureBasicComponents-2" xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:udt="urn:oasis:names:specification:ubl:schema:xsd:UnqualifiedDataTypes-2" xmlns:xades="http://uri.etsi.org/01903/v1.3.2#" xmlns:ccts-cct="urn:un:unece:uncefact:data:specification:CoreComponentTypeSchemaModule:2" xsi:schemaLocation="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader file:///C:/Git/Azure/ISRAEL_V1/transformation/SCI/Israel/TaxInvoice/Schemas/Sovos%20Document/Standard%20Business%20Document/SBD.xsd">
	<StandardBusinessDocumentHeader>
		<HeaderVersion>1.0</HeaderVersion>
		<Sender>
			<Identifier Authority="IL">7777777715</Identifier>
			<ContactInformation>
				<Contact/>
				<EmailAddress/>
				<FaxNumber/>
				<TelephoneNumber/>
				<ContactTypeIdentifier/>
			</ContactInformation>
		</Sender>
		<Receiver>
			<Identifier Authority="IL">15</Identifier>
			<ContactInformation>
				<Contact/>
				<EmailAddress/>
				<FaxNumber/>
				<TelephoneNumber/>
				<ContactTypeIdentifier/>
			</ContactInformation>
		</Receiver>
		<DocumentIdentification>
			<Standard>urn:oasis:names:specification:ubl:schema:xsd:Invoice-2</Standard>
			<TypeVersion>1.0</TypeVersion>
			<InstanceIdentifier/>
			<Type>Invoice</Type>
			<MultipleType>false</MultipleType>
			<CreationDateAndTime>2023-04-08T00:00:00Z</CreationDateAndTime>
		</DocumentIdentification>
		<BusinessScope>
			<Scope>
				<Type>Country</Type>
				<InstanceIdentifier/>
				<Identifier>IL</Identifier>
			</Scope>
			<Scope>
				<Type>SenderSystemId</Type>
				<InstanceIdentifier/>
				<Identifier/>
			</Scope>
			<Scope>
				<Type>Mapping.TransformDocument</Type>
				<InstanceIdentifier/>
				<Identifier>SCI-TO-LEGAL_INVOICE</Identifier>
			</Scope>
			<Scope>
				<Type>Mapping.OutputSchema</Type>
				<InstanceIdentifier/>
				<Identifier>TaxInvoice</Identifier>
			</Scope>
			<Scope>
				<Type>CompanyCode</Type>
				<InstanceIdentifier/>
				<Identifier>7777777715</Identifier>
			</Scope>
			<Scope>
				<Type>SenderDocumentId</Type>
				<InstanceIdentifier/>
				<Identifier>305111111</Identifier>
			</Scope>
			<Scope>
				<Type>ProcessType</Type>
				<InstanceIdentifier/>
				<Identifier>Outbound</Identifier>
			</Scope>
			<Scope>
				<Type>BusinessProcess</Type>
				<InstanceIdentifier/>
				<Identifier>Default</Identifier>
			</Scope>
			<Scope>
				<Type>BusinessCategory</Type>
				<InstanceIdentifier/>
				<Identifier>B2B</Identifier>
			</Scope>
			<Scope>
				<Type>Version</Type>
				<InstanceIdentifier/>
				<Identifier>1.0</Identifier>
			</Scope>
		</BusinessScope>
	</StandardBusinessDocumentHeader>
	<svs:SovosCanonicalInvoice>
		<inv:Invoice>
			<cbc:ID>305111111</cbc:ID>
			<cbc:IssueDate>2023-04-09</cbc:IssueDate>
			<cbc:InvoiceTypeCode>305</cbc:InvoiceTypeCode>
			<cbc:Note>Note</cbc:Note>
			<cac:OrderReference>
				<cbc:ID>975626515</cbc:ID>
			</cac:OrderReference>
			<cac:StatementDocumentReference>
				<cbc:ID>zzz</cbc:ID>
			</cac:StatementDocumentReference>
			<cac:AdditionalDocumentReference>
				<cbc:ID schemeID="Additional_Information">Info</cbc:ID>
			</cac:AdditionalDocumentReference>
			<cac:AdditionalDocumentReference>
				<cbc:ID schemeID="Client_Software_Key">757g6fdg</cbc:ID>
			</cac:AdditionalDocumentReference>
			<cac:AdditionalDocumentReference>
				<cbc:ID schemeID="Accounting_Software_Number">az34</cbc:ID>
			</cac:AdditionalDocumentReference>
			<cac:AccountingSupplierParty>
				<cbc:AdditionalAccountID>125847553</cbc:AdditionalAccountID>
				<cac:Party>
					<cbc:IndustryClassificationCode>333ttt</cbc:IndustryClassificationCode>
					<cac:PartyIdentification>
						<cbc:ID>7777777715</cbc:ID>
					</cac:PartyIdentification>
				</cac:Party>
			</cac:AccountingSupplierParty>
			<cac:AccountingCustomerParty>
				<cac:Party>
					<cac:PartyIdentification>
						<cbc:ID>15</cbc:ID>
					</cac:PartyIdentification>
					<cac:PartyName>
						<cbc:Name>Name1</cbc:Name>
					</cac:PartyName>
				</cac:Party>
			</cac:AccountingCustomerParty>
			<cac:Delivery>
				<cbc:ActualDeliveryDate>2023-04-08</cbc:ActualDeliveryDate>
				<cac:DeliveryAddress>
					<cac:AddressLine>
						<cbc:Line>Address</cbc:Line>
					</cac:AddressLine>
				</cac:DeliveryAddress>
				<cac:EstimatedDeliveryPeriod>
					<cbc:StartTime>00:00:00</cbc:StartTime>
				</cac:EstimatedDeliveryPeriod>
				<cac:CarrierParty>
					<cac:Contact>
						<cbc:Telephone>2345566777</cbc:Telephone>
					</cac:Contact>
				</cac:CarrierParty>
				<cac:Shipment>
					<cbc:ID>0</cbc:ID>
					<cac:ShipmentStage>
						<cac:TransportEvent>
							<cac:Location>
								<cac:Address>
									<cac:AddressLine>
										<cbc:Line>AAA</cbc:Line>
									</cac:AddressLine>
								</cac:Address>
							</cac:Location>
						</cac:TransportEvent>
					</cac:ShipmentStage>
					<cac:TransportHandlingUnit>
						<cac:TransportMeans>
							<cac:RoadTransport>
								<cbc:LicensePlateID>ABC556</cbc:LicensePlateID>
							</cac:RoadTransport>
						</cac:TransportMeans>
					</cac:TransportHandlingUnit>
				</cac:Shipment>
			</cac:Delivery>
			<cac:AllowanceCharge>
				<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
				<cbc:Amount>1700.14</cbc:Amount>
			</cac:AllowanceCharge>
			<cac:TaxTotal>
				<cbc:TaxAmount>170.17</cbc:TaxAmount>
			</cac:TaxTotal>
			<cac:LegalMonetaryTotal>
				<cbc:LineExtensionAmount>10000.8</cbc:LineExtensionAmount>
				<cbc:TaxExclusiveAmount>8300.66</cbc:TaxExclusiveAmount>
				<cbc:PayableAmount>10000.8</cbc:PayableAmount>
			</cac:LegalMonetaryTotal>
			<cac:InvoiceLine>
				<cbc:ID>1</cbc:ID>
				<cbc:InvoicedQuantity unitCode="Kilo">36</cbc:InvoicedQuantity>
				<cbc:LineExtensionAmount>115.8</cbc:LineExtensionAmount>
				<cac:AllowanceCharge>
					<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
					<cbc:Amount>5.8</cbc:Amount>
				</cac:AllowanceCharge>
				<cac:TaxTotal>
					<cbc:TaxAmount>5.8</cbc:TaxAmount>
					<cac:TaxSubtotal>
						<cbc:TaxAmount>0</cbc:TaxAmount>
						<cbc:Percent>17</cbc:Percent>
						<cac:TaxCategory>
							<cbc:ID>0</cbc:ID>
							<cac:TaxScheme>
								<cbc:ID>0</cbc:ID>
							</cac:TaxScheme>
						</cac:TaxCategory>
					</cac:TaxSubtotal>
				</cac:TaxTotal>
				<cac:Item>
					<cbc:Description>Description</cbc:Description>
					<cac:CatalogueItemIdentification>
						<cbc:ID>234</cbc:ID>
					</cac:CatalogueItemIdentification>
					<cac:AdditionalItemIdentification>
						<cbc:ID>5</cbc:ID>
					</cac:AdditionalItemIdentification>
				</cac:Item>
				<cac:Price>
					<cbc:PriceAmount>99.9</cbc:PriceAmount>
				</cac:Price>
			</cac:InvoiceLine>
		</inv:Invoice>
	</svs:SovosCanonicalInvoice>
</StandardBusinessDocument>

Local format

Invoice data sample for a domestic B2B transaction:

<?xml version="1.0" encoding="utf-8"?>
<StandardBusinessDocument xmlns="http://www.unece.org/cefact/namespaces/StandardBusinessDocumentHeader" xmlns:svs="http://www.sovos.com/namespaces/sovosDocument" xmlns:sci="http://www.sovos.com/namespaces/sovosCanonicalInvoice" xmlns:ad="http://www.sovos.com/namespaces/additionalData" xmlns:sov="http://www.sovos.com/namespaces/sovosExtensions" xmlns:enc="http://www.sovos.com/namespaces/base64Document" xmlns:ext="urn:oasis:names:specification:ubl:schema:xsd:CommonExtensionComponents-2" xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2" xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2">
	<StandardBusinessDocumentHeader>
		<HeaderVersion>1.0</HeaderVersion>
		<Sender>
			<Identifier Authority="IL">123456777</Identifier>
		</Sender>
		<Receiver>
			<Identifier Authority="IL">18</Identifier>
		</Receiver>
		<DocumentIdentification>
			<Standard>ILInvoice</Standard>
			<TypeVersion>1.0</TypeVersion>
			<InstanceIdentifier/>
			<Type>Invoice</Type>
			<MultipleType>false</MultipleType>
			<CreationDateAndTime>2023-10-18T17:08:00Z</CreationDateAndTime>
		</DocumentIdentification>
		<BusinessScope>
			<Scope>
				<Type>Country</Type>
				<InstanceIdentifier/>
				<Identifier>IL</Identifier>
			</Scope>
			<Scope>
				<Type>SenderSystemId</Type>
				<InstanceIdentifier/>
				<Identifier>ERPSystem</Identifier>
			</Scope>
			<Scope>
				<Type>Mapping.TransformDocument</Type>
				<InstanceIdentifier/>
				<Identifier>LEGAL-TO-SCI_INVOICE</Identifier>
			</Scope>
			<Scope>
				<Type>Mapping.OutputSchema</Type>
				<InstanceIdentifier/>
				<Identifier>TaxInvoice</Identifier>
			</Scope>
			<Scope>
				<Type>CompanyCode</Type>
				<InstanceIdentifier/>
				<Identifier>123456777</Identifier>
			</Scope>
			<Scope>
				<Type>SenderDocumentId</Type>
				<InstanceIdentifier/>
				<Identifier>ISRAEL|20231018170800</Identifier>
			</Scope>
			<Scope>
				<Type>ProcessType</Type>
				<InstanceIdentifier/>
				<Identifier>Outbound</Identifier>
			</Scope>
			<Scope>
				<Type>BusinessCategory</Type>
				<InstanceIdentifier/>
				<Identifier>B2B</Identifier>
			</Scope>
			<Scope>
				<Type>SubSchema</Type>
				<InstanceIdentifier/>
			</Scope>
			<Scope>
				<Type>Version</Type>
				<InstanceIdentifier/>
				<Identifier>1.0</Identifier>
			</Scope>
			<Scope>
				<Type>BusinessProcess</Type>
				<InstanceIdentifier/>
				<BusinessService>
					<BusinessServiceName>Default</BusinessServiceName>
				</BusinessService>
			</Scope>
		</BusinessScope>
	</StandardBusinessDocumentHeader>
	<svs:SovosDocument>
		<svs:SovosLegalDocument>
			<enc:Base64Document>
				<enc:EmbeddedDocument id="1" fileName="invoice.json" mimeCode="application/json">eyAiSW52b2ljZV9JRCI6IjIwMjMxMDE4MTcwODAwIiwgIkludm9pY2VfVHlwZSI6MzA1LCAiVmF0
X051bWJlciI6MTIzNDU2Nzc3LCAiVW5pb25fVmF0X051bWJlciI6MTIzNDU2Nzg5LCAiSW52b2lj
ZV9SZWZlcmVuY2VfTnVtYmVyIjoiOTc1NjI2NTE1IiwgIkN1c3RvbWVyX1ZBVF9OdW1iZXIiOjE4
LCAiQ3VzdG9tZXJfTmFtZSI6InRlc3QgY3VzdG9tZXIiLCAiSW52b2ljZV9EYXRlIjoiMjAyMy0x
MC0xOCIsICJJbnZvaWNlX0lzc3VhbmNlX0RhdGUiOiIyMDIzLTA5LTE0IiwgIkJyYW5jaF9JRCI6
IjEyMzEyIiwgIkFjY291bnRpbmdfU29mdHdhcmVfTnVtYmVyIjozMjEzMjEsICJDbGllbnRfU29m
dHdhcmVfS2V5IjoiNDU2Nzg5IiwgIkFtb3VudF9CZWZvcmVfRGlzY291bnQiOjEwMDAwLjgwLCAi
RGlzY291bnQiOjE1LjQwLCAiUGF5bWVudF9BbW91bnQiOjEuMDAsICJWQVRfQW1vdW50IjoxLjAw
LCAiUGF5bWVudF9BbW91bnRfSW5jbHVkaW5nX1ZBVCI6MS4wMCwgIkludm9pY2VfTm90ZSI6InRl
c3QgaW52IG5vdGUiLCAiQWN0aW9uIjo0LCAiVmVoaWNsZV9MaWNlbnNlX051bWJlciI6MSwgIlBo
b25lX09mX0RyaXZlciI6IjAyNjUxNTYxNDkiLCAiQXJyaXZhbF9EYXRlIjoiMjAyMy0wNC0wOCIs
ICJFc3RpbWF0ZWRfQXJyaXZhbF9UaW1lIjoiMTE6NTUiLCAiVHJhbnNpdGlvbl9Mb2NhdGlvbiI6
MSwgIkRlbGl2ZXJ5X0FkZHJlc3MiOiIxIiwgIkFkZGl0aW9uYWxfaW5mb3JtYXRpb24iOiIxIiwg
Ikl0ZW1zIjpbIHsgIkluZGV4IjoxLCAiQ2F0YWxvZ19JZCI6NTU2OTg3NTQzNywgIkNhdGVnb3J5
IjoxNSwgIkRlc2NyaXB0aW9uIjoidGVzdCIsICJNZWFzdXJlX1VuaXRfRGVzY3JpcHRpb24iOiJ0
ZXN0IiwgIlF1YW50aXR5Ijo0NTAuNTAsICJQcmljZV9QZXJfVW5pdCI6OTkuOTAsICJEaXNjb3Vu
dCI6NTguMDAsICJUb3RhbF9BbW91bnQiOjExNS44MCwgIlZBVF9SYXRlIjoxNywgIlZBVF9BbW91
bnQiOjUuODB9IF19</enc:EmbeddedDocument>
			</enc:Base64Document>
		</svs:SovosLegalDocument>
	</svs:SovosDocument>
</StandardBusinessDocument>