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.
Workflow
To send an e-invoice, do these steps:- Validate the JSON invoice data while you develop.
- Create the document. The API accepts only an invoice that it can convert to valid UBL BIS Billing 3.0.
- 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
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.
is_valid: true, an empty issues list and the generated UBL in ubl_document. The UBL is shortened here.
Valid
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
Create the invoice
Send the same JSON payload toPOST /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.
201 Created with the complete document in the DRAFT state. Amounts are strings in the response. The response is shortened here.
id. You use it to send the document. If the API rejects the payload, see Create document errors.
Invoice structure
Main fields
Only theitems array is mandatory in the schema. But the API accepts a document only if the generated UBL passes the Peppol BIS Billing 3.0 rules. Thus a complete invoice also needs the fields that this table marks as mandatory, the vendor and customer identifiers, and vendor_name. For the full list, see the document schema.
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 theitems array is one product or service:
For all line fields, see the LineItem schema.
Optional fields
Payment details
Payment details
Additional addresses
Additional addresses
Of these fields, only
shipping_address and shipping_address_recipient go into the UBL (as the delivery). The API stores the billing, service and remittance addresses with the document, but the receiver does not get them.Allowances and charges
Allowances and charges
References and notes
References and notes
buyer_reference is the reference that the buyer asks for (BT-10). When it is absent, the API writes purchase_order as the buyer reference. For the reference to a preceding invoice, see Create credit notes.Send the document
Send the document withPOST /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.
200 OK with the document. The state is now TRANSIT, because the delivery runs in the background. The response is shortened here.
Peppol ID routing
When you send a document, the API finds each of the four Peppol values (sender scheme and identifier, receiver scheme and identifier) in this order:- The query parameter of the send request.
- The Peppol ID that the API stored with the UBL of the document when you created it. For a document that you created from UBL, this is the
cbc:EndpointIDof the party. - The derivation from the identifiers in the document:
customer_peppol_idfirst for the receiver, thenvendor_company_id/customer_company_idandvendor_tax_id/customer_tax_id. ForSELFBILLING_INVOICEandSELFBILLING_CREDIT_NOTE, the direction is reversed: the API derives the sender from thecustomer_*fields and the receiver from thevendor_*fields.
0208 and the enterprise number: the tax ID BE1018265814 gives the Peppol ID 0208:1018265814. If a tax ID has no country prefix, the API uses the country code at the end of the address (for example 1980 Zemst, BE). Always give the VAT number with its country prefix, because rule BR-CO-09 rejects a VAT number without it. For the scheme that the API derives in other countries, see Peppol ID schemes.
When the API sends the document on the Peppol network, it writes the final sender and receiver values in the cbc:EndpointID elements of the UBL that it transmits. The other content of the UBL does not change.
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.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.
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.
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 asinvoice.json, and replace the vendor fields and the Peppol IDs with your data.
Validate, create and send (Node.js and Python)
Validate, create and send (Node.js and Python)
Credit notes and other document types
A credit note has the same structure as an invoice. Setdocument_type to CREDIT_NOTE:
Credit note
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