What starts the two-day clock

Our target is the first valid test invoice within two working days. People hear that and ask when the two days start. The honest answer is: when seven things are in place. This e-⁠invoicing readiness checklist is those seven things. Before they are in place, nobody can promise a date, including us, because the work that takes the time is waiting on something only you can provide.

This note walks through the seven items, why each one matters, who owns it and where projects usually stall. Tick them off below as you read. The clock starts when all seven are ticked.

• A representative set of invoices, covering every variant in scope
• Working access to the source, or a stable file or API handoff
• Test credentials, certificates and taxpayer authorisation, issued to you
• The route chosen, with its test environment active
• A technical owner on your side, available during the window
• Written decisions on tax codes, exemptions, payment data and identifiers
• A webhook URL for the returned status

0 / 7 in place. The clock has not started yet.

Why the clock starts at readiness

A signature tells us you want the work done. It does not give us the invoices, the access or the decisions the work needs. If we started counting on the day of signature, the two days would be spent waiting for an export or a test login, and the target would mean nothing.

So the target is tied to readiness instead. Readiness is a short list, it is the same for every route, and each item has one owner. When the last item arrives, we have everything we need to map, validate and send a test invoice, and the two working days are ours to keep. The glossary calls the same list the readiness package.

This also makes delays easy to talk about. If the test invoice is late, the question is not "who is slow?" but "which item is missing, and who owns it?" Both sides can see the answer.

The e-⁠invoicing readiness checklist, item by item

1. A representative set of invoices

We need real invoices from your ERP, covering every variant in scope: standard invoices, credit notes, and the unusual ones such as reverse-charge lines, foreign-currency invoices or invoices that cite an order. The mapping is built from these. A variant we never see is a variant we cannot test.

Owner: your team. The usual gap is a set that holds only the easy cases.

2. Working access to the source

We read the invoice data where your ERP produces it. That can be working access to the source system, or a stable handoff: the same file or API call every time, with test data in it. A one-off spreadsheet made by hand does not count, because production will not look like it.

Owner: your team. The usual gap is an export that still changes from week to week.

3. Test credentials, certificates and taxpayer authorisation, issued to you

Every route has its own way of letting a company in: a token, a certificate, an authorisation on a tax portal, an account at an access point or platform. These are issued to your company, in your name, on the route you chose.

Owner: your team. The usual gap is a request that is still with the platform.

4. The route chosen, with its test environment active

The route is the way your invoice reaches its buyer in one country: Peppol, a French platform, KSeF, RO e-⁠Factura and so on. You choose it, and its test environment must be switched on for your company. We connect it.

Owner: you choose, we connect. The usual gap is a test environment that exists on paper but is not active yet.

5. A technical owner on your side, available during the window

Someone on your side has to answer questions while we work: where a field comes from, why a code looks the way it does, whether a test invoice may be sent. Two working days do not survive a three-day wait for an answer.

Owner: your team. The usual gap is a name with no time set aside.

6. Written decisions on tax codes, exemptions, payment data and identifiers

Some questions are not technical. Which VAT category applies to this line? Which exemption reason goes on that one? Which identifier do we use for the seller and the buyer? These are tax decisions, and they belong to you and your accountant. We need them in writing, so the mapping follows your decisions and not our guesses.

Owner: your team, with your accountant. The usual gap is a decision taken in a meeting and never written down.

7. A webhook URL for the returned status

Every route answers differently. We turn each answer into one event your ERP can read, with the route's own code kept alongside. For that we need somewhere to send it: a webhook URL on your side, or an agreement that you read the status through the API.

Owner: your team. The usual gap is a URL that nobody on the ERP side is listening to yet.

What happens in the two working days

Once the seventh item arrives, the work runs in a fixed order. We build the mapping from your invoices to EN 16931 [1] and the country's format, check every variant against the official rules, and send invoices through the route's test environment. The status comes back to you the way it will in production. Press play to follow one invoice through.

▶Play

1. 01ERP export
2. 02Mapping
3. 03Validation
4. 04Route
5. 05Buyer and tax platform

↺Status comes back by webhook or API: accepted, rejected with a code, or refused by the buyer.

ERP exportERP data

Your ERP produces the invoice data: a report, a file or an API call.

What can go wrongA field is missing from the export, such as the buyer's VAT number.

The target is the first valid test invoice within those two working days. A valid test invoice is one the route's test environment accepts. It is the first piece of proof that your data, our mapping and the route agree with each other.

Where the seven items fit in the six steps

The readiness list is not a separate process. It is the part of our six steps that only you can start. Here is how the work splits once the scope is signed:

Step	What you do	What we do
Scope	Bring the case and the entity's details	Check it against the standard unit
Map	Give access and representative invoices	Build the mapping table
Validate	Decide tax codes and identifiers	Run the rule sets and fix the mapping
Test	Arrange the test credentials	Send, confirm and map the status
Go live	Run your acceptance test and sign off	Watch the first live invoices
Monitor	Fix data at source when asked	Triage, mapping fixes and the monthly report

Items 1, 2 and 6 feed the mapping and validation steps. Items 3, 4 and 7 feed the test step. Item 5, the technical owner, keeps all of them moving.

What items 3 and 4 mean on three routes

The words on the list are the same everywhere, but the work behind them depends on the route: a KSeF token in Poland [2], a Peppol ID in Belgium, a registration with a Plateforme Agréée in France [3].

• KSeFPL

  Item 3: access, issued to you

  A KSeF token or certificate with the invoice-issuing permission for your NIP

  Item 4: the test environment

  KSeF’s test environment

  Watch for

  A token without the InvoiceWrite permission cannot open a sending session, so KSeF never sees the invoice

• PeppolBE

  Item 3: access, issued to you

  An account at a certified access point, and the Peppol ID your company is registered under

  Item 4: the test environment

  Your access point’s test setup

  Watch for

  Without your Peppol ID as the seller’s electronic address, a Peppol rule rejects the invoice

• Plateforme AgrééeFR

  Item 3: access, issued to you

  Your registration with the platform, with your SIREN active in the national directory

  Item 4: the test environment

  The platform’s test environment, separate from production

  Watch for

  Test and production are separate: being set up in one is not being set up in the other

Two of the three failures stop a test before any buyer sees it. KSeF will not open a sending session for a token without the InvoiceWrite permission [4], and on Peppol the rule PEPPOL-⁠EN16931-⁠R020 rejects the invoice before it leaves [5]. That is why both items sit on the readiness list, before the clock starts, and not inside the two working days.

In France the national directory works in both directions. A company that has not chosen a receiving platform is missing from it, and invoices addressed to that company cannot be delivered [6].

What the clock does not cover

Some steps are outside the two days because neither side controls them. The figure shows where they sit next to the clock.

ReadinessAt your paceThe two working daysOn the clockAfter the first valid test invoiceOn your sign-off

Your teamThe seven items on the listAnswers questions within the windowAcceptance test and sign-off

EurInvoiceConnects the route you choseMaps, validates and sends test invoicesWatches the first live invoices

1. Clock starts: all seven items in place
2. First valid test invoice

Outside the clock

• Platform onboarding and KYC
• Taxpayer authorisation for production
• Third parties, such as an ERP vendor changing an export

• Platform onboarding and KYC, which the access point or platform runs at its own pace.
• Taxpayer authorisation for production, which the tax administration grants.
• Your acceptance test, which your team runs and signs off.
• The availability of third parties, such as an ERP vendor who must change an export.

None of these is a reason to wait before starting the seven items. Most of them can run in parallel with readiness, and starting them early is the best way to keep the whole project short.

Some work is also outside the standard unit itself. More entities or countries, inbound flows, e-⁠reporting, archiving, ERP interface work and platform fees are quoted separately. Knowing that up front keeps the two-day target about one thing: the first valid test invoice.

When an item is missing

It happens on most projects, and it is fine. When an item is missing, we say which one, who owns it and what exactly is needed. The clock waits. Nothing is lost except time, and the readiness list makes it visible where the time goes.

A message from us about a missing item reads like this: "Item 3 is still open. The platform has not activated your test account yet. Owner: your team. Once it is active, send us the account ID and the clock can start." Short, specific, and with one owner.

If a missing item turns out to be on our side, such as the route integration, we say so in the same way. The list applies to both of us, and it is the same list whether you buy from us directly or through your ERP partner.

A checklist to send to your team

Copy this into an email to whoever owns the ERP side:

1. A representative set of anonymised invoices, every variant in scope.
2. Access to the source, or a stable file or API handoff with test data.
3. Test credentials, certificates and taxpayer authorisation for the chosen route, issued to your company.
4. The route chosen, with its test environment active.
5. One technical owner with time set aside during the window.
6. Written decisions on tax codes, exemptions, payment data and identifiers.
7. A webhook URL for the returned status.

When all seven are done, tell us, and the two working days start.