Skip to main content

Overview

With the e-invoice.be API you create an invoice from JSON. The API converts the JSON to UBL that complies with the European e-invoicing standard (EN 16931) and transmits the document on the Peppol network.

Before you start

Develop and test with a sandbox company. A sandbox company runs in test mode: the API sends each document as UBL XML to the contact email address of the company, and nothing goes to the Peppol network. The API host and the endpoints are the same as for a production company. See Test mode and sandbox companies.
You need the API key of the company. See Authentication.

Workflow

To send an e-invoice, do these steps:
  1. Validate the JSON invoice data while you develop.
  2. Create the document. The API accepts only an invoice that it can convert to valid UBL BIS Billing 3.0.
  3. Send the document. A production company sends on the Peppol network. A sandbox company sends an email.
Validation is not a separate mandatory call. POST /api/documents/ rejects a payload that does not pass the same rules. Use POST /api/validate/json while you develop, because it returns all rule failures and the generated UBL.

Validate the invoice data

The examples on this page use this payload:
Invoice
Replace the vendor fields with the data of your company. The API rejects a document if the Peppol ID of the vendor is not one of the peppol_ids of your company. POST /api/validate/json does not create a document and does not check the vendor. Thus you can validate the example without changes.
A valid payload gives is_valid: true, an empty issues list and the generated UBL in ubl_document. The UBL is shortened here.
Valid
A payload that breaks a rule gives is_valid: false. Each entry in issues has a message, a type (error or warning) and the name of the rule set in schematron. The fields rule_id, flag, location and test are optional.
Not valid
See the validation guide for the rules and the corrections. For all status codes and error formats, see Errors and troubleshooting.

Create the invoice

Send the same JSON payload to POST /api/documents/. Replace the vendor fields with the data of your company before you run this example: the API returns 406 if the Peppol ID of the vendor is not one of the peppol_ids of your company.
The API returns 201 Created with the complete document in the DRAFT state. Amounts are strings in the response. The response is shortened here.
Keep the id. You use it to send the document. If the API rejects the payload, see Create document errors.

Invoice structure

Main fields

Only the items array is mandatory in the schema. The other fields are optional for the API, but a complete invoice needs them to pass validation. For all fields, see the document schema. For the amounts (subtotal, total_tax, invoice_total, amount_due), see Invoice totals and calculations.

Vendor fields

The vendor is the seller. This is your company.
The vendor_tax_id is the VAT number of the company. It is not the Peppol ID. For a Belgian company, give the full VAT number with the BE prefix, for example BE1018265814. The API derives the Peppol ID from it when you send the document.

Customer fields

The customer is the buyer.

Line items

Each object in the items array is one product or service:
For all line fields, see the LineItem schema.

Optional fields

See Advanced invoicing.
To send a PDF or a different file with the invoice, see Attachments and PDF.

Send the document

Send the document with POST /api/documents/{document_id}/send. Set the environment variable DOCUMENT_ID to the id from the create response. Replace the sender Peppol ID in the query with the Peppol ID of your company.
The API returns 200 OK with the document. The state is now TRANSIT, because the delivery runs in the background. The response is shortened here.
For the errors of this call, see Send errors.

Peppol ID routing

When you send a document, the API finds the sender and receiver Peppol IDs in this order:
  1. The query parameters of the send request.
  2. The Peppol IDs that the API stored with the UBL of the document.
  3. The identifiers in the document: vendor_tax_id or vendor_company_id for the sender, and customer_peppol_id, customer_tax_id or customer_company_id for the receiver.
For a Belgian party, the API derives scheme 0208 and the enterprise number: the tax ID BE1018265814 gives the Peppol ID 0208:1018265814. For other countries, the derived scheme can be different from the scheme that the receiver registered. Thus the best practice is to give all four query parameters:
cURL
string
Scheme of the sender Peppol ID. Example: 0208.
string
Identifier of the sender, without the scheme. Example: 1018265814.
string
Scheme of the receiver Peppol ID. Example: 0208.
string
Identifier of the receiver, without the scheme. Example: 0848934496.
The API returns 400 if it cannot find a complete sender and receiver Peppol ID. It returns 409 if the sender Peppol ID is not one of the peppol_ids of your company.
Before you send, make sure that the receiver is registered on the Peppol network with the Peppol ID that you use. See Look up Peppol participants.
For the Peppol schemes and the check of a receiver, see Look up Peppol participants.

After the send request

The result depends on the type of company:
  • Production company: the API transmits the document on the Peppol network. The receiver gets it in the software that is connected to its Access Point.
  • Sandbox company: the API sends the UBL XML to the contact email address of the company. Nothing goes to the Peppol network. See What a send does in test mode.
The code is the same for the two types of company. Only the API key is different.

Document states

You can send a document only when it is in the DRAFT or FAILED state. For the transitions, the retry behaviour and the webhook events of each state, see Document lifecycle and delivery tracking. To follow the delivery, use webhooks or request GET /api/documents/{document_id} until the state is SENT or FAILED. If the state is FAILED, see A document is in state FAILED.

Complete example

These programs do the three steps in sequence. Save the example payload from Validate the invoice data as invoice.json, and replace the vendor fields and the Peppol IDs with your data.

Credit notes and other document types

A credit note has the same structure as an invoice. Set document_type to CREDIT_NOTE:
Credit note
This credit note has positive amounts. Replace the vendor fields with the data of your company. The API rejects a document if the Peppol ID of the vendor is not one of the peppol_ids of your company. See Create credit notes for partial credits and corrections, and Self-billing and debit notes for the other values of document_type.

Next Steps

Document lifecycle and delivery tracking

Follow the states and the delivery of a document

Look up Peppol participants

Find the Peppol ID of a customer

List, filter and manage documents

List, find and delete documents

Webhooks

Get a notification for each delivery result