E-invoicing and procurement for a public body

Problem

Invoicing a public administration is not a change of paper format. The XML has to validate before it leaves, the submission can fail for reasons that have nothing to do with the invoice, the status has to be polled afterwards, and an invoice already registered is not deleted: its cancellation is requested. Around all that, a public body does not spend against a generic budget, it spends against a procurement file with its budget chapter and its annual instalments.

Solution

An e-invoicing console inside the ERP itself. It generates the XML, validates it, submits it, tracks the status of each document and handles cancellation requests. Server tasks retry whatever failed, which on an external submission channel is part of the job and not a rare case.

The public-sector administrative cycle is modelled alongside it: procurement files, budget chapters and annual instalments, so every invoice knows what it hangs from.

The accounting side closes the loop, with accrual entries, proration and inventory valuation together with their accounting classification.

Architecture

Why it is built this way

Generating and validating the XML are separate steps from submitting it, so a format rejection is caught here before it occupies the channel.

Cancellation is not a delete. It is a request with its own status and its own tracking, because an invoice already registered with the administration cannot be removed from our side.

I put the retries in server tasks. Nobody sits in front of a screen waiting for the administration to answer.

Every invoice hangs off a procurement file with its budget chapter and annual instalments, which is how public-sector spending is justified.

Accrual entries, proration and inventory valuation are calculated inside the add-on. Moving them outside meant, in practice, a spreadsheet somebody maintained by hand.

Result

226 commits and around 39,000 lines for a public body.