The Parts Nobody Talks About
When I started working on B2B e-invoicing, I thought the technical part would be straightforward. Generate a PDF, embed an XML, follow a standard. On paper, it seemed linear.
In practice, it turned out to be something completely different.
The biggest challenges had nothing to do with generating XML or producing a PDF. They came from everything surrounding the invoice: managing business states, guaranteeing deterministic execution, preventing duplicate processing, and making sure every generated document could be traced back to a single, reproducible operation.
Those are the problems that rarely appear in technical documentation, yet they are the ones that determine whether an invoicing pipeline remains reliable in production.
Multi-period invoicing is a state problem, not a calculation problem
Invoicing across multiple months in a single document seems simple. It is not.
The real issue is that a period included in an issued invoice is permanently closed. It cannot be invoiced again, partially modified, or silently regenerated. This is not a software limitation, but a business and accounting requirement.
To guarantee this behavior, I modeled an explicit state for every invoicing period and every client using immutable archive flags. No database, only deterministic, traceable, immutable files.
Deduplication without a database
Another challenge was preventing the same invoice from being generated twice.
The solution is intentionally simple: file-based locks.
Before every execution, the pipeline checks whether a lock already exists. If it does, the invoice is skipped. Otherwise, it is generated and immediately locked.
No race conditions.
No distributed transactions.
No external dependencies.
Each execution produces a single deterministic result.
A Pipeline Designed to Stop
The entire pipeline runs from cron.
There is no persistent background process, no daemon to supervise, and no service that must remain alive between executions. The engine starts, processes the required work, archives the results, then exits.
This design makes every execution independent and reproducible. If something fails, there is nothing to restart or recover. The logs describe exactly what happened, the archived files provide the evidence, and the next execution starts from a known state.
What I Take from This
Building a reliable invoicing pipeline wasn't primarily a PDF or XML problem.
It was an architecture problem.
Once state management, deterministic execution, and traceability were solved, generating the invoice became the simplest part of the workflow.
Go Further
Explore more technical articles
Read more technical notes
Top comments (0)