The e-invoice is mandatory. Retyping it is not.

Counting comes before assuming: how many invoices arrive per month, by which route, in which formats, from how many suppliers. Almost always structured e-invoices, PDFs and a remainder of paper sit side by side, and almost always the structured share is larger than expected. Those numbers decide what is worth automating and what stays manual.

An off-the-shelf invoice portal is the right choice if you have no target system with an interface, if your approvals can follow the vendor standard, and if you want a product with support rather than something of your own. Then buy it, and I will tell you so in the first conversation. Building is worth it when the target system is already in place and has an interface, when the approval rules should follow your organization rather than the other way round, and when the data should reach the accounts without an import file. The difference is not quality, it is where the manual work is left over: with a portal at the crossing into the ERP, with a built path nowhere. And if you already have a portal, it can serve as an inbound channel. There is nothing against that.

Any format complying with EN 16931 is permitted, along with formats agreed between the parties such as EDI. In practice that means XRechnung and ZUGFeRD from 2.x, and those already carry the fields inside them: supplier, invoice number, line items, tax rates, bank details. These invoices are read, not recognized, which makes them the only part of the inbound flow that can be processed without uncertainty. One exception gets checked right at the start: the ZUGFeRD MINIMUM and BASIC-WL profiles are not an e-invoice within the meaning of the law. Anyone receiving those has a PDF with an attachment and needs to go back to the supplier.

At the starting price PDF and paper go to a person for review: they are not lost, they are seen before a posting is made. Whether automatic text extraction is worth it for them is decided by the volume profile, and it is added afterwards as an offer of its own. It then works with a confidence value: what is certain moves on, what is uncertain goes back to a person rather than writing itself unnoticed into the accounts. That line is drawn deliberately and can be moved later, once you can see how often it applies.

Supplier against master data, amount and line items against purchase order and goods receipt, a three-way match where the data supports one, bank details against the ones on file, invoice number against what is already posted. The reading happens over the same interface the posting is later handed over through; checks that need a further integration are quoted beforehand rather than built in quietly. Duplicates and deviations surface before they trigger a payment, for the documents running through the channel that was built. How strict the checks are follows your data, not a default setting.

Who approves up to which amount, who stands in during absence, what happens without a purchase order and what happens on a dispute: these are rules in the system, with deadlines and reminders. Approving happens where the work happens anyway, through a link by email or in the inbox of the system you already run. No approval portal of its own and no user administration of its own is built. An approval is then an event with a timestamp and a person, not an email somebody kept.

The checked invoice goes to your ERP or your accounting system as a journal entry, over whatever interface exists there. The original document stays stored unchanged, every step is recorded and attributable to a person. Whether the retention then satisfies the obligations is for your tax adviser to judge; my job is that the technical conditions for it remain met.