2.3
Before go-live: what the client brings
What the client brings before the clock starts.
- In the sandboxchecklist
In plain words
Before a go-live starts, the client hands over a fixed list: a sample export, access to the source, a route with a test environment, a credential for the route's network or authority, and written tax decisions. The clock for the first test invoice starts only when the list is complete, so a late item pushes the date back. The client and the partner bring the list; we check it and record GO or NO-GO.
Note
The go-live clock starts when this list is complete. Platform onboarding, identity checks, taxpayer authorisation, the client's own acceptance testing and third-party availability sit outside the clock.
Every route
- The client's legal entity and its tax ID in that country.
- A sample ERP export that covers every invoice variant in scope.
- Working access to the source, or a stable file or API handoff.
- A selected route with an active sandbox.
- The rail credential the route needs. It goes in through the credentials API, never by email.
- Written decisions on tax codes, exemptions, payment data and identifiers.
- A named technical owner on the partner's side for the work window.
- A place for returned status: a callback, a file or a queue. We check it with a sample event that passes the schema.
By route
| Route | The client also brings | Outside the clock |
|---|---|---|
DE-XRECHNUNG | Nothing for Germany itself. By email: the sending mailbox and the buyers' invoice addresses. Over Peppol: registration at the access point. | The access point's identity check, if Peppol is used. |
PEPPOL | The buyer's participant id and its scheme on each invoice. Consent to register the client as a Peppol participant. | The access point's identity check before production. |
FR-PA | The client's own platform account, its consent on that platform, and API credentials per company. | An identity check of the legal representative and a company check, before the client's address is registered. |
PL-KSEF | A KSeF token that can send invoices and, for statuses, read them, issued by the client's KSeF administrator. Official sources disagree on how long tokens work (see rail credentials). | The administrator issuing the credential. |
RO-EFACTURA | Authorisation for our ANAF application, given in a browser by the company's legal representative or its accountant with SPV rights for the company's CUI. | That authorisation step. |
Rail credentials covers each credential in detail.