e-Factura integration: invoices that send themselves from your software

When you issue a handful of invoices a month, you can upload them by hand to Spațiul Privat Virtual (SPV), the online portal of ANAF, Romania’s tax authority. When you issue dozens a day, from your ERP or your online store, manual uploading becomes a job in its own right, and mistakes creep in exactly when things are busiest. An e-Factura integration moves that work into the software: the invoice is issued once, and the software takes it the rest of the way.

e-Factura is Romania’s national e-invoicing system. Invoices reach it as structured XML files, through a programming interface provided by ANAF, and for each invoice the system returns a status and a response. Who is required to submit, which documents and by when are questions for your accountant: we build the tool; we do not interpret the law.

An invoice’s journey, from issue to ANAF’s response

The software saves the invoice and builds the XML file from its data, in the structure the system requires. The file goes out through ANAF’s interface, which acknowledges receipt. The result comes later: the invoice has either passed validation or been rejected, with the errors found.

The part most often forgotten is that the result does not come back straight away. The software has to ask again, at reasonable intervals, and must not treat an invoice as “submitted” just because the file has gone. That is why every invoice has its own status: to be sent, pending, accepted, rejected, to be resent.

• Checks before sending: missing mandatory fields, mistyped tax identification codes, totals that do not add up.
• Status tracking: the software queries the system until it gets a final result.
• Keeping the response: the file returned by the system is archived alongside the invoice.
• Alerts: the right person is notified when an invoice is rejected or has got stuck.

An e-Factura integration is judged by how it handles errors

Technical errors (the system being unavailable, a response timing out) are dealt with by automatic retries, at ever longer intervals. Content errors, meaning invoices rejected at validation, do not fix themselves: they go to someone on your team, with the message received, explained in plain language as far as possible, and a direct link to the invoice.

That leaves the most awkward case: the connection drops just after sending and you do not know whether the invoice arrived. The software has to find out what happened first and only then resend. Otherwise it sends a second copy of a document that has already been received, and the way the system treats duplicates has changed over time and is checked at the time of the project.

Questions to settle before the first line of code

Work starts with a conversation that your accountant should ideally join: what types of document you issue (invoices, reversal invoices, foreign-currency invoices, advance invoices), how many programs they come from and who is responsible for them. This is also when it is decided who obtains access to the interface: authorisation is carried out, with their own digital certificate, by a person who already has access to Spațiul Privat Virtual on the company’s behalf, not by the developer.

Next comes the data inventory. The structured format requires information that many older programs do not hold separately: county and town in distinct fields, a unit of measure chosen from a list of codes, a VAT rate on every line. Cleaning up the master data is part of the project and often takes longer than the programming.

• Testing: submissions in the test environment, where one is available, with no effect on real invoices.
• Supervised running: real invoices go out automatically, but someone checks them daily for a while.
• Handover: documentation, a monitoring screen and someone on your team who knows what each status means.

Queues, logs and where it all runs

We usually write the connection as a separate module, in PHP with Laravel or in Python, which talks to your software through the database or through an API (a gateway through which two programs exchange data with no human involvement). The invoicing software itself is left untouched, and the submission side can be updated when the technical requirements change.

Submissions pass through a job queue, that is, a list of tasks carried out one at a time, in the background, without depending on anyone’s browser. Every step is written to a log: what was sent, when, and what the system replied. Access credentials are stored encrypted, and when renewing them needs a person, the software gives advance warning.

When you do not need custom development

If you use ordinary off-the-shelf invoicing software, it very probably has submission built in already. There is no point paying for something written from scratch; at most, it is worth connecting it to your store or your ERP.

Custom development has its place when invoices originate in a system of your own or when you invoice from several sources. One thing holds either way: automation submits whatever it is given. An invoice that is wrong in your software arrives wrong in the system too, only faster.

This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.