What is actually in the file
An e-invoice is more revealing than most people expect when they drag one into a web form. In a single XML there is typically:
- the IBAN the money is meant to arrive on — the one field that is worth altering, and the one people do try to alter;
- two VAT identifiers, which tie the document to real registered companies;
- the customer's name and address, which in many industries is the part your competitors would actually like;
- and prices per line — that is, your margin, if anyone cares to compare.
None of that is secret in the sense of a password. It is simply commercial information that has no reason to leave the building for the sake of turning XML into columns.
01 — The claim
"Files are deleted after an hour"
That sentence appears on nearly every converter, and it may well be true. The trouble is that it is unverifiable from the outside: you cannot see the server, the backups, the logs, or who else has an account on that machine.
It is also a promise about the future made by a company whose future you do not control. "Deleted after an hour" and "not sent at all" are not two strengths of the same assurance — they are different kinds of statement.
02 — The check
Anyone can verify "not sent at all"
This is the useful asymmetry: a claim about not transmitting can be checked by the person making the decision, in the browser they already have open, without trusting anybody.
- Open the developer tools (F12) and go to the Network tab.
- Drop an invoice on the page.
- Watch what appears. If the file is being uploaded, a request appears carrying it — the size gives it away.
Then the stronger version: load the page, disconnect the network, and drop the file anyway. A tool that works offline cannot be sending anything, because there is nothing to send it to.
Run that check on this page
Everything above applies to Ledgerdrop as well, and it is meant to: the reason the check is worth describing is that it works against us too. Drop a file on the main page with the network tab open and no request goes out. Pull the network and it keeps working.
Being precise about what that does not mean: loading the page itself is an ordinary web request, so the fact that you visited is visible in the usual way. Fonts and the page's own code come from the network the first time. What does not move is the invoice.
If the file has to be uploaded somewhere
Sometimes there is no way around it — a tax portal, an access point, an archive service. In that case the useful questions are the ordinary ones, and they are worth asking in writing: who is the data processor, where does the data sit, how long is it kept, and who can reach the backups.
The point of this page is narrower: format conversion is not one of those cases. Turning an XML invoice into a table is arithmetic on a file you already have. It needs no server, and a tool that asks for one anyway should say why.
What runs here instead
The parser is the page. It reads UBL and CII, Factur-X and ZUGFeRD PDFs, FatturaPA
including signed .p7m, Facturae, KSeF, RO e-Factura, Austrian ebInterface,
Hungarian NAV and Finnish Finvoice, plus ZIP archives and email attachments — and turns
them into one row per invoice, checked against the
EN 16931 rules by number.
Up to 10 invoices per export and 20 a day, free, no account, and the count resets at midnight. Pro lifts both limits for 29 € once, with no renewal.