{"id":28933,"date":"2026-07-24T08:32:00","date_gmt":"2026-07-24T08:32:00","guid":{"rendered":"https:\/\/bilnex.io\/saas-e-arvete-lisamine\/"},"modified":"2026-07-24T08:32:00","modified_gmt":"2026-07-24T08:32:00","slug":"adding-invoices-to-saas-e","status":"publish","type":"page","link":"https:\/\/bilnex.io\/en\/adding-invoices-to-saas-e\/","title":{"rendered":"How to add e-invoicing to your SaaS product?"},"content":{"rendered":"
\n
\n
\n

If your users request e-invoices, your product needs four capabilities: create invoices that comply with the European standard EN 16931, deliver them over the network that buyers use (in Europe, primarily Peppol<\/a>), validate documents before sending and, if desired, accept invoices. The question is not \u201eif\u201d, but \u201ehow\u201d: in Estonia, EN 16931 from July 1, 2025, the primary e-invoice format<\/a> and registered buyers can demand e-invoices \u2013 your users are already feeling the pressure today. There are two options: build your own certified access point or consume an existing one via your own API.<\/p>\n

What does \u201edo-it-yourself\u201d really mean?<\/h2>\n

Becoming a certified access point is a compliance project, not a development task: OpenPeppol membership, certification, running an AS4 messaging infrastructure, an SMP service for managing participants, and keeping up with rulebook updates throughout the network release cycle. This is the right path if the e-invoicing infrastructure IS your product. If e-invoicing is one feature among others in your product, you will pay for this path in quarters of development time before the first customer value.<\/p>\n

What does \u201eready-to-use API\u201d mean?<\/h2>\n

Integration project: Your application POSTs billing data to a certified provider's API, receives synchronous validation with understandable errors, delivery statuses with webhooks, and participant management as API operations. Accreditation, transport, and rule updates are the responsibility of the provider. The timeline is another world: with a documented API, first test document in one working day<\/a> realistic, typically reaches production in weeks. We have written out the technical side (formats, validation layers, statuses) in the developer guides sending e-invoices via API<\/a> and About creating a UBL invoice<\/a>.<\/p>\n

How to decide? Three questions<\/h2>\n

First: is e-invoicing the core or the support of your product? The core justifies its infrastructure, the support does not. Second: how many markets do you need to cover? Every country adds rules \u2013 B2B e-invoicing is changing in Latvia mandatory in 2028<\/a>, the Lithuanian state receives invoices via Peppol: and the API provider handles this paperwork for you. Third: who is responsible at night? An access point is an infrastructure whose failure will stop the flow of money to your users; ask yourself honestly if you want it on duty.<\/p>\n

Checklist for selecting a provider<\/h2>\n

Certified access point status. Synchronous validation with structured errors. Sandboxing with separate keys. Webhooks signed and idempotent. Participant registration and migration via API, not tickets. And documentation that your developer doesn't have to call support for: the latter predicts the quality of collaboration most accurately.<\/p>\n<\/div>\n<\/div>\n<\/article>\n