AI and e-invoicing: what can be automated

On e-invoicing, there is a misunderstanding: because the document is a structured file, it is thought that it needs AI to read it. That's not where it makes. VAT, taxable and rates already stand in fields defined by the track: just a traditional parser, which costs less and does not make unpredictable errors.

The work that is really worth automating begins after: understanding what that invoice line refers to, verifying that it complies with terms and formats provided by the standard, deciding where it should be archived for the years in which it must remain available. They are different tasks, and should be treated as such instead of all being placed in the same project.

The Exchange System, in brief

Each electronic invoice passes from a single checkpoint before arriving at its destination. The Exchange System, managed by the Revenue Agency, is the computer system that receives the files in the InvoicePA path, carries out formal checks on each and only then forwards them to the public administration or the recipient private subject, as described by the same Revenue Agency on the Invoice portalPA. A file that does not pass those controls does not arrive at its destination and, above all, has no fiscal value: it is an aspect that an automation project must treat as a real document status, not as a technical detail to be ignored until it gives problems.

For those who build an automatic stream this means predicting from the beginning what happens when the SdI discards a file: who is warned, how long, and if the correction falls within the emission terms seen later. A project that only handles the positive case, i.e. the invoice accepted on the first attempt, works in demo and jams at the first real waste.

It is no small detail: the issue missed or late is subject to the administrative sanctions provided for in Article 6 of Legislative Decree 471/1997, the same as recalled by the rule on the obligation extended to the flat rates to define the period of tolerance of the first application. A system that reports a waste the same day, instead of at the close of the month, is the one that keeps the company within the terms instead of out.

When the invoice is to be issued, and the role of the transport document

The invoice, whether electronic or paper, shall be issued within a specified period from the time when the transaction is deemed to have been carried out, as determined by the Article 21 of Presidential Decree 633/1972. The same rule provides an exception for those who deliver goods tracked by a transport document: in that case it is possible to group in a single document all the supplies made to the same customer in the same calendar month, the so-called deferred invoice. For those who ship goods with a certain frequency to the same customers, this distinction decides whether the project generates twelve invoices per customer per year or one per day: it is worth knowing before drawing the flow, not after. The link between the two documents is described more closely in AI for Logistics and Shipping.

Since 2024 the obligation also concerns those who are flat-rate

Until a few years ago, those who adhered to the flat-rate scheme remained outside the requirement for electronic invoicing. This is no longer the case: the obligation applies from 1 July to those who have exceeded a revenue threshold in the previous year, and from 1 January following all other flat-rate entities, without exceptions related to turnover, as established by the Article 1 of Legislative Decree 127/2015. For a small firm or a flat-rate VAT number that manages the administration on its own, this means that data mining and automatic sorting of incoming documents are no longer a structured business luxury: they also concern those who bill a limited number of customers on their own.

The combination of invoice and order: the case that is worth more

The job that absorbs the most time in administration is not inserting the invoice: it is understanding what it refers to. The supplier describes the same item differently than the order you sent him, the quantity does not coincide because there were partial deliveries, and someone ends up opening three documents and comparing them by eye.

1. The system reads the lines of the invoice, including textual descriptions.
2. Look for matches between open orders from the same provider.
3. It proposes pairing with a level of certainty, not as a definitive data.
4. The clear matches pass; the doubtful ones end up in a queue with the written motivation.
5. Differences in quantity or price with respect to the order are explicitly highlighted, not hidden in a total that returns anyway.

Storing is not just saving a file

The retention obligation to the standard concerns both the emitter and the recipient of the electronic invoice, according to Article 39 of DPR 633/1972, and is a process technically regulated by the Code of the Digital Administration, not a copy on a shared disk, as the Revenue Agency Guide to the Preservation of Electronic Invoices. Those who do not want to rely on a private conservative can use the free service that the Agency makes available from the reserved area of Invoices and Fees. An automation project that stops at accounting registration and does not predict where and how the invoice will remain available has solved only half of the problem.

Invoices contain data of natural and legal persons, so any external service that reads them, ranks them or matches them to orders processes personal data for all purposes. Before entrusting the flow to a supplier it must be verified where the documents are processed, if they remain in the company's availability and if they are used to train third-party models: the complete framework, with the legal bases to be put in writing, is in GDPR and AI in the company. It is a verification that is done only once, at the beginning, not a fulfillment to be sent back to the initiated project.

Passive cycle and active cycle are not the same bet

The passive cycle, where you receive documents produced by others, is where the project yields the most: you don't check the format of descriptions, so each supplier writes in its own way and serves interpretation. In one example: a company that receives invoices from different suppliers with linked orders can see manual matching absorb several minutes for each non-trivial document, a time that is significantly reduced when the system already proposes correspondence.

The sales invoicing cycle is different: you generate the content, so it already follows your internal rules and requires much less interpretation. A business issuing only a few invoices each month to regular clients, with amounts agreed in advance, will rarely find a project that pays for itself. In that case, the value lies in issuing invoices on time within the deadlines, rather than in a system that interprets documents. It is still worth automatically monitoring the issue deadlines discussed above, because this error is easy to make precisely when the sales invoicing cycle seems too simple to warrant attention.

There is, however, a point of contact between the two cycles that is worth noting: the moment when a wrong passive invoice generates, cascaded, a credit note to be issued on its active cycle. If the project only looks at the side it receives, that waterfall remains invisible until someone notices it when it closes, and at that point correcting costs more time than it would have required intercepting it immediately.

Signals that the project is not yet ready

• No system-registered orders. Without an order to compare with, pairing has nothing to work with.
• Incomplete or duplicate supplier registry. The system does not recognize who issued the document and multiplies the exceptions.
• Business software that does not allow automated writes. The data extracted must still be rebutted by hand, and the project stops in half.
• Few documents per month, always from the same suppliers. A rule automation costs less and works just as well.

If you recognize more than one of these signals, it is not said that the project should be abandoned: often it just means that another work should be anticipated, such as fixing the supplier registry or recording orders that today live only in emails, also described in AI for procurement and supplier management. It is worth doing this check before talking to a technology provider, not after: a project built on top of a dirty registry inherits the mess and amplifies it instead of solving it, and the disappointment that follows usually does not depend on the chosen system but on what was fed to it from day one.

On e-invoicing the AI is not used to read the document: it is used to understand what it refers to, verify its timing and decide where it will end up in a few years when someone will look for it again. They are three different tasks, with different regulatory sources behind them, and that is why it is worth separating them from the design instead of buying a single tool that promises to do everything without distinction.

The general framework of administrative functions that lend themselves to a first project is in AI for Accounting, while the choice between custom-built or relying on a ready tool is in AI by subscription or customized. If you want to see how it works in practice on your documents, Giallo Studio has a data entry automation demo built right on this type of stream.