When choosing a tool that takes data out of a document, the question people ask is “how accurate is it”. That is the right question badly framed, because accuracy is not one thing: it depends on the type of value, and for some of them it is not even an estimate.
Three values that can be verified
An Italian VAT number is eleven digits, and the last one is a check character computed from the first ten with the Luhn algorithm. An individual’s tax code ends with a letter computed from everything before it. An IBAN carries two check digits, computed under the standard from the remainder of a division by 97.
The practical consequence is that on these three a program does not guess: it computes and compares. If the character matches, that is a VAT number; if it does not, it is eleven digits in a row. Not a probability, a yes or a no.
The real gain is in false positives. An eleven-digit reference number in a document is not mistaken for a VAT number, because the check does not match, so it is not replaced with a placeholder that would make the text unreadable.
Verifying does not mean asking somebody
There is a confusion worth clearing away, because it is the one people designing these tools fall into most often. “Verifying a VAT number” in accounting usually means something else: querying VIES or the tax authority’s service to see whether it exists and whose it is. That is a check of existence, and it is extremely useful, when you are issuing an invoice.
Here it would be the exact opposite of the job in hand. Sending that VAT number to an outside service to find out whether it is valid means letting the value you were about to substitute leave the office, and letting it leave before the document itself does. An anonymiser that calls an online database to check the values it finds has added a recipient instead of removing one.
The check character is interesting precisely because it asks nobody anything: it is arithmetic on numbers you already have, computed on the machine in a thousandth of a second. It is the only form of verification compatible with a tool that has to work with no network and without telling anybody what it is looking at.
Everything else is a proposal
A company name, a personal name, an address, an amount, a date: none of these carries a check character. They are recognised from how they are written and where they sit in the sentence, which means a model, and a model gives a probability.
Where it goes wrong most often is something that happens constantly in accounts: a company name that is also an ordinary word. A cautious detector catches them all, and the text fills with placeholders in place of normal words; a permissive one misses some, and a missed one is client data that left.
Neither setting is the right one, which is why review is not an optional step: the machine proposes, the person decides. Nothing in Omissia is substituted without having been seen, at the point in the document where it sits.
The question to ask whoever is selling you a tool
“It recognises VAT numbers” is an answer everyone gives. The useful question is different: does it verify them against the check character, or recognise them by shape. That difference takes two minutes to measure, with a VAT number that is wrong by one digit: if the tool replaces it anyway, it is recognising eleven digits in a row.
The second question is whether the vocabulary is Italian. A product built elsewhere recognises its own country’s names, addresses and social security numbers, and on Italian accounts it leaves the VAT number, the tax code and the land registry data without mentioning that it left them.
How to test a tool in half an hour
The two possible errors do not cost the same, and that difference is what decides the choice. A false positive, an ordinary word mistaken for data, is visible: the text comes out with a placeholder where none was needed, and whoever rereads it notices. A false negative, a value left in the clear, is invisible by definition, because the document looks fine. It is the only error that leaves the office.
From which comes a test worth more than any datasheet, and you run it before buying. Take five real documents from the firm, of different kinds: a set of accounts, a payslip, a tax return, a contract, a scan. Count by hand the identifying values they contain: it is tedious, and you do it once. Then put them through the tool and compare.
The three questions the test answers are: how many values it missed; whether any of the missed ones carried a check character, which should never happen; and whether it found anything at all in the scan, because a document with no text layer is where half the products find nothing and do not say so. A tool that declares the values it found and shows them one by one makes this test possible; one that hands back only the cleaned document does not. And that difference is not about accuracy, it is about being checkable.
Why it matters more here than elsewhere
In an accounting document the direct identifiers are numerous and repeated: the VAT number in the heading, IBANs in the payments, tax codes in the schedules, and again in the attachments. They are also the values that identify with no reasoning at all, unlike a company name that has to be looked up somewhere.
Leaving one behind wastes all the rest of the work. That is why the three values with a check character deserve an algorithm rather than an estimate. What still identifies a company without its name is in the piece about accounts.