Send e-invoices
Creating e-invoices in Monite is similar to creating regular invoices, with a few key differences.
One of the differences is that e-invoices go through additional statuses - issuing
and (optionally) failed
.
Only draft
and newly created invoices can be sent as e-invoices.
Already issued invoices cannot be re-sent as e-invoices.
However, issued e-invoices can be resent via email.
This guide assumes that:
The following diagram shows the basic flow of the e-invoice sending process in Monite:
Before creating an e-invoice, the entity needs to specify the PEPPOL ID of its counterpart. Counterpart PEPPOL IDs can be filled in even before the entity has completed e-invoicing onboarding.
Counterpart lookup
You can use GET /einvoice_search
to check if a counterpart is registered in PEPPOL.
This tells you whether the counterpart’s PEPPOL ID is their VAT number, business number, or both.
Another way to find the PEPPOL ID of a company is to search the public PEPPOL directory for the company name or address.
You can specify counterpart PEPPOL IDs in two ways:
If a counterpart has several PEPPOL IDs with different schemes, you can add them all and later have the entity users choose the PEPPOL ID to send the e-invoice to.
Companies usually share their PEPPOL IDs in the format <code>:<identifier>
, such as 9930:DE087095777
.
To add this identifier to a counterpart, do the following:
Split the string by :
.
Call POST /counterparts/
. In the request body, provide the scheme name and identifier obtained on the previous step:
In case of the <country>:VAT
schemes, the identifier value starts with a two-letter country prefix.
Do not remove this prefix.
A successful response contains a Monite id
assigned the counterpart’s PEPPOL ID.
Note down this id
- you will need it later when creating e-invoices for this counterpart.
If the counterpart has a VAT ID defined and you know that the counterpart is registered in PEPPOL using this VAT ID, you can send the id
of the VAT ID object in the request to POST /counterparts/
:
In this case, Monite infers the scheme name (network_schema
) of the PEPPOL ID from the country
of the VAT ID object.
A successful response contains a Monite id
assigned the counterpart’s PEPPOL ID.
Note down this id
- you will need it later when creating e-invoices for this counterpart.
When you add a counterpart’s PEPPOL identifier, Monite validates the format and length of the specified network_identifier
and checks if it is actually registered on the PEPPOL network.
If the specified identifier is not registered in PEPPOL or has incorrect length or format, you will receive an HTTP 409 error from POST /counterparts/
.
Identifier is not registered in PEPPOL:
Wrong identifier length or format:
In the sandbox environment, the predefined test counterpart identifiers pass the validations.
Create a new draft invoice in the usual way, but with the following additional fields:
Example:
Entity address and VAT number that will be included in the e-invoice XML are taken from the entity’s e-invoicing registration (/einvoicing_connections
) and its PEPPOL identifier (network_credentials_id
) rather than from the address and VAT ID of the entity object itself.
While an invoice is still in the draft
status, you can change its is_einvoice
field to turn e-invoicing on or off for this invoice.
The response returns the full invoice data, along with the PEPPOL ID details of the entity and counterpart:
Before issuing an invoice, call POST /receivables
to make sure all required fields are filled in.
After a draft invoice has been finalized, call POST /receivables/
to send the e-invoice through the e-invoicing network.
When an invoice has is_einvoice
=true
, the /receivables
endpoint works as follows:
Monite checks again if the counterpart’s PEPPOL ID exists on the PEPPOL network.
If not, /issue
returns an HTTP 409 error containing a substring “No action taken”.
The invoice remains in the draft
status.
Monite checks if all data required for an e-invoice is filled in.
If not, /issue
returns an HTTP 409 error and the invoice remains in the draft
status.
Users can fill in the missing data and attempt to send the e-invoice again.
If the previous checks succeed, /issue
returns HTTP 200 OK.
The invoice is moved from the draft
to issuing
status, and the receivable.issuing
webhook is triggered.
Monite attemts to send the document to the counterpart through the e-invoicing network.
If the e-invoice is successfully sent (that is, successfully routed to the counterpart’s PEPPOL access point):
issued
and the receivable.issued
webhook is triggered.If the invoice failed to be sent via e-invoicing:
failed
and the receivable.failed
webhook is triggered.einvoice_error_comment
field of the invoice.It may take a few minutes for an invoice to move from the issuing
status to issued
or failed
.
If you need to send an e-invoice both as an e-invoice and via email, do not use /receivables
for a draft invoice as a shortcut for /issue
+ /send
.
Instead, call /issue
as explained above, wait until the invoice status becomes issued
, and only after that call /send
.
When an e-invoice or credit note gets issued, Monite generates the e-invoice XML document in the PEPPOL BIS Billing format and stores a link to this file in einvoice_file_url
field of the invoice or credit note.
This is the same XML document that gets sent to the counterpart over the e-invoicing network.
Example file contents:
If the partner setting mail.attach_documents_as_pdf
it true
,
this XML file is also automatically attached to invoice and credit note emails sent by POST /receivables
.
Credit notes inherit e-invoicing details (such as the counterpart’s PEPPOL ID) from the invoice they are based on. If the original invoice was configured for e-invoicing delivery, the credit note will also be sent via e-invoicing, and vice versa.
Like e-invoices, credit notes go through additional statuses when sent via e-invoicing.
E-invoicing connections and entity PEPPOL IDs created in the sandbox environment are erased periodically and should be considered temporary. Other entity data in the sandbox - users, e-invoices, and so on - is preserved.
In the sandbox environment, send e-invoices and credit notes to the following test counterparts:
E-invoicing webhooks receivable.issuing
and receivable.failed
are not triggered in sandbox.
Dutch Peppol authority has additional guidelines for e-invoice testing in the Netherlands, in particular:
Sensitive data
In accordance with AVG/GDPR regulations test messages should not contain any references to personal information.
Any content of messages sent via the Peppol test infrastructure referring to personal information must be redacted or faked.
commercial_condition_description
deductions
, deduction_amount
, and deduction_memo
footer
memo
vat_exempt
=false
and vat_exemption_rationale
withholding_tax_rate
C62
code (“one”, “unit”) instead of the specific codes (such as hour, kg, or meter).Receive e-invoices