1. Why an API instead of another invoice system
If your source data already exists, copying it into another tool is usually the wrong workflow. The API connects to your existing billing logic.
BOFU API
German e-invoicing API for structured invoice data
Your software already has the invoice data. Fakturai gives that workflow a clear API boundary: structured data in, ZUGFeRD / Factur-X output out, technical validation report attached.
It is not a new accounting suite. It is a focused layer for teams that need German e-invoice output from an existing SaaS, ERP, marketplace or back-office system.
Public proof
The smallest Fakturai workflow is inspectable: one sample invoice JSON with a Berlin seller, Munich buyer, EUR currency, invoice date, due date, line item, 19 percent VAT, payment terms and delivery date.
The technical validation report shows validation_status: passed, format ZUGFeRD / Factur-X EN 16931, KoSIT validator profile EN16931-CII, hard_failures: [] and advisory_findings: [].
Note: Technical format validation does not replace the issuer's responsibility for invoice content, tax treatment, or archival.
sample invoice JSON · technical validation report · ZUGFeRD / Factur-X output
2. The technical flow
Your system sends structured invoice data. Fakturai generates ZUGFeRD / Factur-X output and runs a technical format validation.
3. What the proof shows
The proof shows the payload, expected output boundary and a passed technical validation report. It does not provide tax advice or an archive policy.
4. Where Fakturai fits
SaaS billing, marketplace invoicing, internal ERP flows, agency automation and back-office workflows with an existing invoice data source.
5. Where Fakturai does not fit
Teams looking for a full accounting suite, invoice UI, tax advice, archive strategy or content approval workflow.