Incoming e-Factura invoices: from supplier straight into approval

Until recently, a supplier invoice arrived by email or in an envelope, and somebody knew about it. Now it can appear directly in e-Factura, Romania’s national e-invoicing system, without the person who ordered the goods ever finding out. A module that collects incoming e-Factura invoices brings the documents into the company’s software shortly after they appear and puts them in front of the people who need to see them: purchasing, stock management, accounting.

Downloading is the easy part. What matters is what comes next: you identify the supplier, find the order, compare the quantities with what came into the warehouse, and find out in good time whether you have been invoiced for something you did not ask for.

The inbox nobody opens

In a company with many suppliers, incoming invoices end up being checked in fits and starts: someone logs in to Spațiul Privat Virtual (SPV), the online portal of ANAF, Romania’s tax authority, when they remember, downloads archives and retypes the data into the stock management software. In the meantime the goods have been received on the strength of the delivery note, and nobody in purchasing has seen the official document.

This is where the usual troubles come from: invoices recorded twice (once from the PDF that came by email, once from the system), prices that differ from those negotiated and are noticed only at payment, and invoices issued by mistake against your tax identification code by companies you do not deal with. Your accountant will tell you how to proceed in each case; the software’s job is to show them to you in time.

Incoming e-Factura invoices in three moves: download, read, match

The module queries the system at regular intervals through ANAF’s programming interface, downloads everything new and keeps the original files exactly as they arrived. It then reads the XML: supplier, number, dates, lines with quantities, prices and VAT rates. Because the format is structured, there is no need for text recognition as there would be with a scanned PDF.

Then comes the matching. The invoice is set beside the purchase order and the goods received note, and the software compares the three documents. Whatever matches within the limits you have chosen moves on. The rest stops, with the discrepancy clearly stated.

• The supplier: identified by the tax identification code on the invoice.
• The order: found by the number quoted on the invoice, or by products and period.
• The goods receipt: quantities invoiced against quantities booked into stock.
• The price: the invoiced price against the order price, with a tolerance you choose.
• Unexpected invoices and duplicates: an unknown supplier, no open order, or a number already recorded.

Who approves what: the workflow after matching

We design the approval workflow around how decisions are actually made in your company. Imagine you have three sites and a finance director: invoices that match perfectly go straight to accounting, those with discrepancies go to the person who placed the order, and those above a value you choose need a second signature.

The approver gets the invoice, the order and the goods receipt side by side and can approve, reject or ask for clarification. Everything is recorded in the history, and when someone is away, the task passes to their designated deputy.

At the end, the approved invoice is exported to the accounting software, with accounts or cost centres suggested according to rules agreed with your accountant. The accountant validates the entry.

From the supplier list to the first real invoices

We start with what you already have: the supplier list, what your orders and goods receipts look like, and the accounting software that receives the result. Purchases made without a written order (utilities, rent, subscriptions) get a separate route, with direct approval.

The download service runs in the background, on the server, and is usually written in Python or in PHP with Laravel. It connects to stock management and accounting through an API where the software has one (an official route by which another program reads and writes its data), or through import files.

• The kick-off discussion: with purchasing, stock management and your accountant around the same table.
• The matching rules: what counts as “the same”, which tolerances you accept, what is always held back.
• The trial: a few dozen invoices already received, run through the system.
• The phased start: download and flagging first, then matching, and export last.

What the software cannot decide for you

Automatic matching works only as well as your orders are organised. If half your purchases are made over the phone, the system will flag half your invoices as unexpected, and rightly so. The fix is a matter of internal discipline, not code.

Nor does the software know whether an invoice is correct for tax purposes or whether it should be disputed: it shows you that there is a problem and whose problem it is. It is also unwise to rely on the national system as your archive. The downloaded copies are kept on your side, and for how long and in what form is something you settle with your accountant.

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.