For field service, job management and ERP platforms
Your platform already turns a work order into an invoice
A technician closes the job, the invoice goes out, and it lands in your customer's accounting system. Sending it on Peppol is a different job: every one of your customers is a separate business on the network, with its own identity. That is the part teams underestimate, and it is the part getpeppr handles.
Short answer
What you keep
You keep the invoice. Your platform decides what is billable, applies the rates, and produces the totals — nothing about that changes.
What we handle
We take your JSON, generate and validate the Peppol BIS 3.0 document, register each customer in a supported country as its own legal entity, send under that identity, and return delivery status on a webhook.
Ordinary Peppol invoicing from France works today; French regulated CTC remains a private pilot, not general availability.
Why the accounting export is not Peppol
Most field service platforms already push invoices into an accounting or ERP system. That solves bookkeeping. It does not put the invoice on the network, and it is the gap customers run into first.
Exporting to accounting is not sending on Peppol
An export hands the invoice to another system and stops there. Peppol delivery is a separate act: the document has to be built to a legal format, validated, addressed to a registered participant, and transmitted through an access point that both sides trust.
The invoice has to be structured, not printed
A PDF attached to an email is not an e-invoice. Peppol carries UBL — a machine-readable document with mandatory fields, code lists and validation rules. Validation separates fatal violations, which stop the send, from advisory warnings, which do not.
Your customer is the sender, not you
The invoice comes from the plumbing or HVAC company that did the work, not from your software. On the network that means each customer needs its own verified Peppol identity before it can send — and, separately, a published one before it can receive.
One integration, not one per customer
Onboarding every contractor to their own provider account does not scale past the first dozen. What scales is one integration on your side, with each customer sitting underneath it as a separate legal entity.
Transmission only runs through certified access points — OpenPeppol publishes the official list of certified service providers, which is worth checking for any provider you evaluate. getpeppr publishes its own country coverage — check that your customers' countries are on it.
Three steps, in the order you meet them
The parts that are genuinely hard — document format, validation, network addressing — sit on our side of the line. What stays on yours is the sequence below, and one of its steps waits on someone else.
Register the customer
One call creates the customer as a draft legal entity and returns 202; registry verification then runs in the background. In production your customer also confirms an attestation email before their identity goes active — worth designing into your onboarding rather than discovering later. Your master key covers every customer; there is no per-customer account to open.
Send the invoice as JSON
Post the lines, parties and totals your platform already holds. UBL and Peppol BIS 3.0 are generated and validated on our side — no XML in your codebase.
Read the outcome
Status arrives on a webhook: invoice.sent once the document reaches the recipient's access point, then invoice.accepted or invoice.refused when the recipient's system answers, and invoice.error if delivery ultimately fails. Validation problems do not wait for a webhook — they come back on the API call itself.
Weighing providers rather than approaches? See how the Peppol APIs compare →
Frequently asked questions
Does this work if my platform is an ERP rather than field service software?
Yes. The shape of the problem is the same for any platform that issues invoices on behalf of the businesses using it: field service, job management, ERP, project or practice management. What matters is whether your customers are separate legal entities that each need their own Peppol identity — if they are, getpeppr's multi-tenant model applies unchanged.
Do I need to become a Peppol access point to send invoices for my customers?
No. Becoming a certified access point means passing accreditation and running the network infrastructure yourself. Platforms connect through an existing one instead: getpeppr gives you the API, the multi-tenant model and the document generation, and transmission runs over Storecove's certified access point. You integrate once and your customers reach the network through it.
Can my customers send under their own company identity rather than mine?
Yes, and for field service software that is the only correct model: the invoice legally comes from your customer, not from your platform. getpeppr registers each customer as its own legal entity with its own Peppol identity, under a single integration on your side — for customers established in the countries getpeppr publishes coverage for.
My platform already exports invoices to accounting. Is that Peppol?
No. An accounting export moves the invoice into another system — that is bookkeeping. Peppol is the structured delivery of that invoice across the network to the recipient, and the two are different steps. Who sends it matters too: on Peppol the invoice goes out under your customer company's own identity, not your platform's. Whether that delivery satisfies a given country's rules is a separate question — national regimes add their own requirements on top.
Do I have to handle UBL and XML myself?
No. You send JSON containing the invoice data your platform already has. getpeppr generates the UBL, validates it against Peppol BIS Billing 3.0 before transmission, and returns the delivery outcome on a webhook.
What happens when an invoice is refused?
You receive an invoice.refused event on your webhook telling you which document was refused, so your product can flag it to the customer and you can investigate. Structural problems are caught earlier and differently: the document is validated against Peppol BIS Billing 3.0 before transmission, and those failures come back on the API call itself rather than as a webhook later.
Can I try it before committing?
Yes, and the sandbox is where you should start. An organisation admin starts the platform sandbox trial from the console and creates a sandbox master key — no sales call, no credit card. That is enough to register test customers and send validated documents end to end. Production platform access is set up with our team rather than self-serve, so plan that step in once the integration works.
Ready to ship Peppol invoices?
Validate locally or create a free sandbox. No credit card, full SDK access.
$npm install @getpeppr/sdkFree sandbox forever. No credit card required. Production access follows the plan you choose.