E-invoice gap check
Answer a few questions to get an initial indication of whether PEDIF could be relevant as an output layer for PDF-to-e-invoice workflows.
Answered: 0 of 7
Initial assessment
The use case may be relevant, but mandatory fields, layouts or source data should be clarified first. It is especially important to know whether the data is available, clearly identifiable or controllably derivable.
The gap check gives an initial indication of whether there is an e-invoicing gap in your invoicing landscape and whether PEDIF could close it as an output layer. It asks eight questions about your invoice sources, formats, data and target processes. The following sections explain what an e-invoice gap is and how to interpret the result.
In many companies the main invoicing process is already well organized: the ERP creates invoices, and large customers receive them via EDI or a portal. Next to this main process, however, there are often other invoice sources: subsidiaries, specialist billing systems, service or project billing, legacy applications or manual special cases. These sources frequently produce PDF invoices only.
As soon as recipients require structured e-invoices, these PDF invoices become a gap. The gap check helps you find out whether such a gap exists and how it could be closed.
An e-invoice can only contain what is known. If a mandatory value such as a buyer reference, a VAT identification number or a tax category is neither printed on the PDF nor available in master data, no conversion can create it reliably. That is why the gap check asks whether the required data is available. Missing data is not a reason to give up, but it has to be clarified before automation, for example by adding fields in the source system or maintaining reference data per customer.
PEDIF uses the PDF invoices that your systems already produce as the starting point. Recurring layouts are set up once, the invoice data is structured, missing values are added from rules or master data where possible, and the result is created in the required format, validated and handed over for delivery. The source systems stay as they are, and invoices that do not meet the rules are held back for review instead of reaching the recipient with errors.
Invoice sources outside the main process are easy to overlook. A practical way to find them is to look at the accounts receivable ledger and ask, for each group of postings, which system or person created the invoice. Other good sources are the outgoing mail of the accounting department, the email outboxes of sales and service teams and the list of software licences in use. The result is often a longer list than expected, including systems that issue only a few invoices per month.
Not every gap needs to be closed at once. Useful criteria are the number of invoices per source, the recipients' requirements and deadlines, the effort needed to adapt the source system and the share of recurring layouts. Sources with regular volume, recurring layouts and recipients who already require e-invoices are usually the best place to start.
E-invoicing projects usually start with the main ERP, because it creates most invoices. Side systems and special processes are often discovered only when the first recipients reject PDF invoices from them. By then, time is short and the effort is high. Looking for gaps at the beginning of the project, rather than at the end, makes it possible to plan all invoice sources together and to choose the right solution for each of them without time pressure.
