Sovos Docs

Offboarding

The Sovos eArchiving offboarding process involves several steps, including signing an offboarding agreement, locking the company, downloading invoices, migrating them to a new archive, and finally closing and deleting the company.

The Sovos eArchiving offboarding process is essentially based on the lifecycle of a company. As described on the configuration page, it's necessary to use two endpoints to create a company and enable it for storage. Similar endpoints must be used to offboard a company.

To check what status a company is in, you can make a GET request to the /config/{countryCode}/companies/{companyId} endpoint. In addition, you can find the company's status in the Sovos eArchiving GUI.
Note:

It is only possible to offboard all invoices from a given company; it's not possible to offboard only some of a company's invoices.

The diagram below shows the processes needed to offboard the invoices in a company from Sovos eArchiving:A diagram showing the offboarding process

Step 1: Offboarding agreement

An offboarding agreement must be signed before the offboarding process begins. You'll need to explicitly confirm that you are responsible for archiving your own original e-invoices. This confirmation should be explicit and in writing. An offboarding agreement template is available upon request.

Step 2: Lock the Company

You must stop storing new e-invoices in the section before offboarding. Once you have done so, you must send a PATCH request to the /config/{countryCode}/companies/{companyId} endpoint to lock the company for storage.

After the PATCH request is made, the company will no longer perform Store or Update operations. It's now in a locked status, which allows downloading the invoices and attachments.

If there is a need to revert the company status from locked to enabled, your service owner should send an email request to Sovos support.

To make this request, set the following parameters:
NameTypeRequiredParameter typeDescription
countryCodestringYesPathSet it to the company's country code.
companyIdstringYesPathSet it to the company ID to be returned.
statusstringYesRequest bodySet it to "LockedForArchiving".
Note:

See the API Specifications page for more information about the request. In addition, there are full samples on the Postman Samples page.

Request sample
curl --location -g --request PATCH 'https://api-test-tls.sovos.com/v1/config/{countryCode}/companies/{companyId}' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Content-Type: application/json' \
--data-raw '{
	"status": "LockedForArchiving"
}'
Response sample
{
    "timestamp": 1622206829408,
    "status": 200,
    "success": true,
    "message": "Company Locked",
    "data": {}
}

Step 3: Download the Invoices from Sovos eArchiving

There are two ways to download all invoices and attachments from a locked company:
Retrieve the Invoices via the APi
To download the invoices by using the API:
  1. Follow the steps on the Searching for Invoices page until all the references are collected.

  2. Use the references to download all the invoices via the endpoint for Retrieving Invoices.

Download all the Invoices using a URL

As an alternative to using the API, it's possible to download all invoices from a locked company from a URL that Sovos provides upon request. This web page is accessed via HTTPS with your client certificate, which is also used to access Sovos eArchiving via the API. All invoices, attachments, and metadata are streamed from Sovos eArchiving to you. The downloaded data is a stream of XML invoice objects, where each XML invoice object has the same syntax as the output when the invoices are retrieved via the API.

If you use an ordinary web browser, the XML file is saved to the disk. As an alternative, you can also develop a web client that downloads the XML file and potentially parses the invoices, attachments, and metadata from the XML file. The downloaded XML file can be several megabytes or even gigabytes in size. Sovos recommends using a SAX parser -- based on an event-driven algorithm with low memory requirements -- instead of a DOM parser -- which allocates RAM memory for the entire XML document.

If there's a need to perform a reconciliation check on the downloaded invoices, the API endpoints that list and retrieve invoices can be used. The downloaded invoices and the corresponding references downloaded from the web page can then be compared to the identified references.

Step 4: Migrate the Invoices to a New Archive

Once you have downloaded all invoices and attachments, you should migrate the documents to the new archive. This process goes beyond the scope of Sovos's responsibilities.

Step 5: Close the Company

When the invoices have been migrated to the new archive, you must send a PATCH request to the /config/{countryCode}/companies/{companyId} endpoint to close the company.

To make this request, set the following parameters:
NameTypeRequiredParameter typeDescription
countryCodestringYesPathSet it to the company's country code.
companyIdstringYesPathSet it to the company ID to be returned.
statusstringYesRequest bodySet it to "ClosedForArchiving".
Note:

See the API Specifications page for more information about the request. In addition, there are full samples on the Postman Samples page.

Request sample
curl --location -g --request PATCH 'https://api-test-tls.sovos.com/v1/config/{countryCode}/companies/{companyId}' \
--header 'Authorization: Bearer TOKEN' \
--header 'x-correlationId: SET-TO-UNIQUE-VALUE' \
--header 'Content-Type: application/json' \
--data-raw '{
	"status": "ClosedForArchiving"
}'
Response sample
{
    "timestamp": 1622210925597,
    "status": 200,
    "success": true,
    "message": "Company Closed",
    "data": {}
}

Step 6: Delete Company

Finally, your Service Owner should email Sovos support with a formal request to delete the invoices in the companies that have been offboarded according to the steps above.

When Sovos support confirms that the invoices have been deleted in the requested companies, the offboarding process ends.

Error Handling

Adhere to the error handling principles outlined on the responses page.

In general, all error codes in the 400 range are client errors, so analyze them individually. After fixing the error, it's possible to resend the request. Error codes 408 and 429 are exceptions: in these cases, you should wait at least 60 seconds before retrying. The error codes in the 500 range are server errors. In that case, you need to resend the request, according to the instructions given on the responses page, which also includes a full list of error codes the COAPI can return.