Cleared Before It Counts: E-Invoicing Discipline for UK Sellers in Romania and Serbia
The invoice is no longer the document you send
For a UK founder or exporter, an invoice often feels like the least technical part of a cross-border order. The commercial terms are agreed, the goods are prepared, the customs paperwork is assembled, and the invoice is produced at the end. In Romania and Serbia, that sequence is risky. A B2B invoice is not simply a PDF attached to an email; it is a structured message submitted to a national platform, validated there, and then made available to the buyer through that platform.
That distinction matters commercially. If the local buyer cannot retrieve a cleared invoice, its accounts payable team may be unable to post the liability, claim the input tax treatment it expects, or release payment against the agreed terms. The UK seller may believe it has invoiced. The buyer's system may show nothing valid to pay. For finance teams accustomed to PDFs, this is not a formatting inconvenience. It is a break in the evidence chain between dispatch, revenue recognition and cash collection.
The right response is not to ask the IT department to add a new template. It is to treat e-invoicing as part of market-entry compliance, alongside VAT registration, importer-of-record decisions and customs documentation.
Why a PDF cannot travel alone
Romania and Serbia have both built centralised clearance models for domestic B2B invoicing. The precise rules and platform names differ, but the operating principle is similar: the invoice must pass through the state system before it becomes the invoice the buyer can use. A PDF may still be shared for human reference, but it is a representation of the cleared message, not a substitute for it.
This creates several practical traps for UK sellers.
First, an order can be commercially fulfilled but administratively incomplete. Goods may have been delivered, yet no cleared invoice exists. Second, credit notes and corrections follow the same discipline. A UK finance team that can issue a local invoice but cannot issue a compliant credit note has only half a process. Third, the audit trail changes. The platform record, the buyer's acceptance or rejection, and the archived structured file become the evidence a UK parent needs when local accountants, auditors or tax authorities ask what happened.
For a UK business, the key question is not whether a PDF looks professional. It is whether the local buyer can match a cleared invoice number to the purchase order, receive the goods into stock, and process payment without manual intervention.
Two regimes, one operating discipline
The two regimes are not identical, and UK finance teams should avoid designing a single 'Balkans invoice' process that assumes they are. The table below sets out the practical differences that matter before the first local invoice is issued.
| Practical point | Romania | Serbia |
|---|---|---|
| Platform | RO e-Factura, operated through the national tax administration | SEF, the national electronic invoicing system |
| Invoice format | Structured XML based on the national CIUS profile | Structured XML as prescribed by the Serbian system |
| Clearance model | Central submission and validation before the buyer can use the invoice | Central submission and validation through SEF |
| Registration | Requires the relevant Romanian tax and platform credentials, often through a local representative or adviser where the UK entity has no establishment | Requires SEF registration and correctly assigned user roles for the Serbian entity or its representative |
| Buyer interaction | The buyer retrieves the cleared invoice from the platform | The buyer receives and can accept or reject the invoice through SEF |
| Archiving | The structured record and platform evidence must be retained | The structured record and platform evidence must be retained |
| UK-side risk | Assuming a PDF or emailed invoice satisfies the obligation | Assuming a Serbian trading partner will 'handle the system' without a documented role split |
Neither column should be read as a reason to delay. They are reasons to assign ownership early. The common discipline is this: confirm who is the local invoicing entity, register that entity correctly, map the data fields, test validation, and keep evidence of every cleared and rejected message.
Registration is a finance project, not a sales formality
The registration step is where many UK sellers lose time. The commercial team may have agreed a first order, and the local buyer may be pressing for an invoice, but the UK entity may not yet have the credentials needed to submit anything to the platform. In some cases the obligation sits with a local subsidiary, branch or fiscal representative. In others, the UK entity may need a local tax registration before it can invoice at all. The answer depends on the supply, the contractual flow and the local adviser's view.
A sensible UK finance team will therefore build a registration file before the first order is confirmed. That file should identify the invoicing entity, the local tax registration position, the platform administrator, the named users, the buyer's platform identifier, and the escalation contact for rejected messages. It should also record who is responsible for approving credit notes and corrections. Leaving those decisions until the first invoice is rejected is an expensive way to learn the local process.
Software must map data, not just produce a document
Many e-invoicing failures are data failures. The platform may reject a file because a buyer identifier is missing, a tax code is not recognised, a unit of measure is inconsistent, or the currency and VAT treatment do not match the underlying supply. A tool that converts a PDF into XML without validating the underlying master data will simply move the problem downstream.
UK sellers should test the full chain with a real buyer before go-live: purchase order reference, buyer identifier, line-item descriptions, quantities, unit codes, currency, VAT treatment, payment terms and delivery details. Where the UK company uses a global ERP, the local mapping should be documented rather than buried in a consultant's configuration. The finance team should be able to explain which fields are mandatory, which are conditional, and which are derived from the sales order.
Validation, rejection and the evidence trail
Clearance is not the end of the process. A platform validation confirms that the message meets the technical rules. It does not guarantee that the buyer will accept it commercially. Serbian buyers can reject invoices through SEF, and Romanian buyers may dispute the content even after the platform has cleared it. UK finance teams need a rejection workflow with named owners, response times and a clear route for issuing corrections.
That workflow should also cover the human-readable copy. If a PDF is sent to the buyer, it should carry the platform reference and be clearly marked as a representation of the cleared invoice. It should not be the only record. The structured file, the submission receipt and the buyer's response should be retained in a form that local advisers can retrieve during an audit.
A 2026 pre-launch checklist for UK finance teams
- Confirm which legal entity will issue the local invoice and whether any local tax registration is required.
- Obtain the platform credentials and assign named administrators before the first order is confirmed.
- Map buyer identifiers, VAT treatment, currency, unit codes and payment terms from the sales order into the invoice file.
- Test a complete invoice, credit note and correction with the actual buyer, not only with a software vendor.
- Agree who monitors platform rejections and who responds to buyer disputes.
- Document the role split between the UK finance team, the local entity and any fiscal representative.
- Retain the structured file, submission evidence and buyer response in an accessible archive.
- Train sales and customer service teams not to promise 'invoice on dispatch' unless the platform process supports it.
- Include e-invoicing readiness in the go-live gate for any new Romanian or Serbian customer.
- Review the process after the first month of live invoices and record any recurring validation errors.
The control question for the board
The board-level question is simple: can the UK business prove that a local invoice was validly issued, delivered and accepted before it recognises the receivable? In Romania and Serbia, that proof depends on a platform record, not on an email attachment. UK sellers that treat e-invoicing as a finance-controlled market-entry requirement will find the first local invoice unremarkable. Those that treat it as a PDF design task may find that the order was fulfilled but the cash is waiting on a message that was never cleared.
