Skip to main content

Send invoice

Choose how to send your documents
  1. The destination format (EHF Billing 3.0), through the country's invoicing API.
  2. The A-Cube standard CSV, through SFTP or the file upload API using A-Cube Transfer. Transfer converts your files to EHF Billing 3.0.
  3. Your own format, the files your ERP already exports, with A-Cube Transfer. A-Cube builds the conversion to EHF Billing 3.0 during onboarding.

Ask A-Cube to activate A-Cube Transfer and confirm your format and file upload API access for this destination before the first upload.

To send a document, you can choose to build a standard XML UBL 2.1 document or a JSON payload. For more details on supported formats, see Formats.

The Norwegian endpoints accept EHF Billing 3.0 and Peppol BIS Billing 3.0 documents, so you must use one of the following pairs of values within your document:

<cbc:CustomizationID>urn:cen.eu:en16931:2017#compliant#urn:fdc:peppol.eu:2017:poacc:billing:3.0#conformant#urn:fdc:anskaffelser.no:2019:ehf:forward-billing:3.0</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:anskaffelser.no:2019:ehf:postaward:g3:08:1.0</cbc:ProfileID>

If you send a document with a different customization, it will be refused with an HTTP 422 and the message The document is of a type different than what is specified for this endpoint.

The endpoint is: POST /invoices

If the platform cannot manage the document, you will get a response with a body describing the error in JSON and a status code:

  • HTTP 422 in case the validation fails.
  • HTTP 403 in case your account is not enabled for Norway.
  • HTTP 500 in case of a general error server side.

If everything is fine and the validation passes, you will receive an HTTP 202 status and the document resource (with its own unique identifier uuid) as the response. The document has been accepted and prepared for the dispatching through the Peppol network.

The JSON response you will receive contains some useful information:

{
"uuid": "9a163ebe-fb45-4b10-aac3-d5bad66acf40",
"direction": "outgoing",
"format": "UBL 2.1 XML",
"number": "0997462625",
"date": "2019-04-01",
"sender": {
"name": "Havblikk Nett AS",
"identifier": "811143758"
},
"recipient": {
"name": "Buyer AS",
"identifier": "hn0073648"
},
"createdAt": "2026-10-02T14:22:32+00:00",
"downloaded": false,
"peppolMessage": {
"uuid": "282c6c79-9306-421a-8210-2453f03bf52d",
"createdAt": "2026-10-02T14:22:32+00:00",
"requestSentAt": null,
"responseReceivedAt": null,
"success": null,
"errorCode": null,
"errorMessage": null
}
}

Within a short period of time it will be traveling towards the document recipient. Once delivered, you will get notified to your configured webhook.

You can also monitor and download metadata information about the document with GET /invoices/{uuid}. The original document can be downloaded with GET /invoices/{uuid}/source and a printed version with GET /invoices/{uuid}/print.

Check the recipient​

Before sending a document, you can check if the recipient is registered into the Peppol Network with GET /smpquery/{participantId}, where {participantId} is the recipient Peppol identifier (i.e., 0192:987654325).

You will receive an HTTP 200 with the list of the document types the recipient can receive, or an HTTP 404 if the recipient is not registered.

The validation process​

The validation is performed real-time during the API HTTP request.

The document is then validated against the ruleset of its format, EHF Billing 3.0 or Peppol BIS Billing 3.0. It follows an example of validation error response.

{
"status": 422,
"violations": [
{
"propertyPath": "/:Invoice[1]/cac:LegalMonetaryTotal[1]",
"message": "Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).",
"code": "BR-CO-16"
}
],
"detail": "/:Invoice[1]/cac:LegalMonetaryTotal[1]: Amount due for payment (BT-115) = Invoice total amount with VAT (BT-112) -Paid amount (BT-113) +Rounding amount (BT-114).",
"type": "/validation_errors/BR-CO-16",
"title": "An error occurred"
}

The propertyPath indicates the XML node where the error has been found, the message describes the error and the code is the specific validation rule that has been violated.