There is a sentence that comes up in almost every conversation we have with a Romanian finance team: "e-Factura solved the invoices, and made the payments worse."
It is not quite true, but it points at something real. The national system was built to move documents between taxpayers and ANAF. It does that well. It was never built to move money, and nothing about receiving a structured invoice brings you any closer to having paid it. So the compliance half of accounts payable got automated, the payment half did not, and the gap between them is now the most manual part of the month.
This is what that gap actually looks like, and what can be done about it.
What the SPV gives you, precisely
When a supplier issues you an invoice through RO e-Factura, what lands in your Virtual Private Space is a structured XML file — the invoice as data, in a fixed schema, machine-readable by design. Alongside it sits ANAF's electronic seal, which is what makes the document legally the original.
That is a genuinely good format. Every field a payment needs is in there as a labelled value rather than as pixels: the supplier, the total, the currency, the due date, the invoice number, and the bank account the supplier expects to be paid into.
The trouble is what happens next. The SPV is an inbox with a download button. It does not know which invoices you have already paid, it does not group them by supplier or due date, and it will not tell you that the same invoice arrived twice. Every one of those judgements is yours, and most companies make them in a spreadsheet.
The five steps everybody does by hand
Watch a typical accounts-payable afternoon and it decomposes into the same five steps:
- Fetch. Log into the SPV, find what is new since last time, download it. Usually as a batch of XML files, occasionally one at a time.
- Read. Open each one. XML is machine-readable, not human-readable, so in practice this means a converter, an accounting import, or squinting at a browser rendering.
- Decide. Is this ours? Is it right? Was it already paid? Has this supplier's IBAN changed since last month — and if it has, why?
- Re-key. Open internet banking. Type the IBAN. Type the amount. Type a reference. Repeat.
- Reconcile. Later, match the bank statement back to the invoices, and mark them paid wherever you keep that list.
Steps 1, 2 and 5 cost time. Step 4 is where the money risk lives, and it is worth being precise about why.
The re-keying step is not a time problem
A mistyped IBAN is not a compliance failure that gets corrected at the next filing. It is a payment that has left your account and arrived somewhere else. Romanian banks, like banks everywhere, execute on the account number — the beneficiary name you type is not what routes the transfer.
There is a worse version of the same step. Invoice fraud in Romania overwhelmingly takes the shape of a real invoice from a real supplier with one field changed: the IBAN. It arrives by email, it looks exactly like the one that arrived last month, and the amount is unremarkable. The whole attack depends on somebody re-typing a bank account from a document into a payment form without checking it against anything.
Which points at the actual fix. The defence is not "be careful" — it is not typing it at all. If the account number travels from the structured invoice into the payment instruction without a human in between, an attacker has to compromise the invoice at source rather than in your inbox, which is a much harder thing to do.
What "automating" this really means
Automation here is not one thing, and the steps are worth separating, because they have very different difficulty:
- Collection — invoices arriving on their own rather than being fetched. This is solved. ANAF exposes the access; you grant it, and documents arrive.
- Normalisation — the XML becoming a list a person can read, sorted by what is due and what is not. Also solved, and mostly a matter of someone having done the schema work for you.
- Initiation — the payment leaving without anyone re-typing an IBAN. This is the step that needs a licensed connection to your bank, which is what open banking is for. It is also the step where "automated" must not mean "automatic": the authorisation stays with you, at your bank.
- Reconciliation — knowing what settled. Falls out of the previous step almost for free, because a payment that was initiated from an invoice already knows which invoice it belongs to.
Notice which one is missing: deciding what to pay. That is not automation, and it should not be. A payment run is a set of decisions about your money, and the job of the tooling is to put those decisions in front of the right person with the right information, not to make them.
What to keep, whatever tool you use
Even if you never change anything about how you work, three habits pay for themselves:
- Work from the SPV, not from your inbox. An emailed PDF is a notification, not the invoice. It is also the vector for the IBAN swap described above.
- Archive outside the SPV. ANAF keeps e-Factura documents available for a limited window. The invoices you will be asked for during an inspection are, by definition, old ones.
- Separate the person who prepares a payment from the person who releases it, above whatever threshold makes sense for your size. We wrote about doing this without bureaucracy in who approves payments in a small company.
Where OpenPay fits
This is the gap OpenPay was built for. You connect ANAF once and the supplier invoices arrive in one list — you upload nothing. You approve what should go out, and the payment is initiated with your own bank over integrated open banking, so no IBAN is ever re-typed. The authorisation itself happens at your bank, with multi-factor authentication: OpenPay cannot move money on its own.
If the compliance side is what is on your mind right now, start with what changed in e-Factura in 2026.