Validations Prior to Posting/Sending

Status: available soon

Verifications Step 1: when posting via API the send request

When posting the invoice, some basic checks are executed, for example :

• Whether the invoice number has the right format.
• Whether the customer can receive French e-invoices.

Feedback per verification result :

• If one of these checks fails, the API answers right away with an error (400 Bad Request) and a short description of the problem. Nothing is sent, no orderID is created or returned as info.
• If the checks pass, the API answers OK, on OrderID is returned. This only means the invoice is queued for sending. It hasn't been sent yet.

Verifications Step 2: the full check, just before sending

A moment later, usually within seconds to a few minutes, Billit runs the full check: the tax authority rules, the duplicate invoice number check, and the Peppol invoice itself.

Action depending on result:

• If this check fails, nothing is sent and nothing is reported to the tax authority. No retries are done, information is returned quickly.
• If this check has a positive result, processing continues

In case of a verification error :

• No error code: the integrator's request already got its answer in step 1, so this step can't change it.
• Where the error shows up instead: it's added to the invoice's sending history. An integrator sees it by looking up the invoice through the API: the sending attempt shows as failed, with a message such as "Peppol sending cancelled: the invoice number is too long". The same message also appears on the invoice in the app.
• How an API user sees them:
  • Through GET /v1/orders/{orderId}. The order's Messages list then holds the Peppol message with Success = false and a description like Peppol sending cancelled: Invoice number '...' exceeds ....
  • Webhook message will also be posted if Webhooks are active.

Why not do the full check in step 1?

It would be nicer if the send request answered with every error straight away. Today that isn't possible:

• The invoice PDF may not exist yet. It's made in the background after the invoice is approved, and the Peppol invoice contains that PDF. So at the moment of the send request, we often can't build the Peppol invoice yet, let alone check it.
• The exact Peppol format is chosen later. It depends on what the customer's system accepts, and that's looked up just before sending.
• The send request would get slow. The full check takes some time per invoice. An integrator sending many invoices at once would have to wait for all of them.
• The check just before sending is needed anyway. Invoices also get sent in other ways (bulk sends, integrations), and details can change between the request and the actual sending. So this last check stays as the safety net.