Connect electronic invoices with existing business workflows
Extend existing tools where needed and distinguish technical outcomes from business decisions.
An invoice arrives as a structured file. Software can read it and the report contains no format errors. Yet nobody knows which purchase order it belongs to. Calling that state “complete” places an unresolved business problem behind a technically successful operation. This is why introduction needs a view of the whole transaction.
This guide considers a fictional medium-sized business with purchasing, specialist teams and accounting. It develops an original operating model and bounded technical examples. Legal context reflects sources checked on 9 November 2026. Individual cases, tax treatment and retention arrangements need to match the particular business transaction.
1. Separate format requirements from business decisions
Section 14 of Germany's VAT Act describes electronic invoices as structured invoices capable of electronic processing. An ordinary PDF without appropriate structured invoice data does not become such an electronic invoice merely because it is sent electronically. Examine actual content and format rather than the filename alone.
For covered domestic business transactions, the general rule must be considered together with exceptions and transitional provisions. Section 27(38) of the VAT Act includes transitions through the end of 2026 and, where the issuer's previous-year turnover does not exceed EUR 800,000, through the end of 2027. This is not a general extension for every situation.
Technical introduction may be useful independently of a particular issuing deadline. Receipt and further processing require a suitable route. Decide from the formats actually arriving and the organisation's existing capabilities, rather than the latest possible date alone. Public-sector customers and cross-border transactions can raise additional questions that need separate attention.
The business decision follows: does the invoice correspond to a known delivery? Do the service scope and agreed terms match? Who may approve it? Formally correct XML cannot answer those questions. They require information from the organisation and a person responsible for evaluating it.
2. Map an existing transaction completely
Follow one invoice from receipt to accounting handover. Record the mailbox or portal, storage, owner and systems involved. Include changes of medium: is the file printed, a number entered in Excel or a question raised through a separate message? These transitions often reveal where information or responsibility becomes unclear.
Inspect a difficult case too. A missing order reference or an unexpected amount often reveals more than a clean standard invoice. Ask how an unresolved question is recorded and where the invoice remains meanwhile. It must not disappear from view simply because approval has not yet been granted.
Distinguish useful control from accumulated detours. Comparing the invoice with the order may be necessary. Copying its number into three different lists may add no further evidence. The aim is an understandable transaction that preserves necessary decisions while eliminating transfers that do not serve a defined purpose.
Finish the initial review with a small process map. Include receipt, original file, data extraction, technical validation, matching, substantive review, approval and handover. Give each stage an outcome and an owner. This makes it possible to identify which parts are already supported by existing software and which require a focused addition.
3. Make receipt a controlled handover point
A central intake helps maintain an overview when it matches the agreed delivery routes. It may include an appropriate mailbox. A portal or another transport mechanism can provide additional metadata. Describe how each received file becomes one identifiable internal case rather than an anonymous attachment waiting in a folder.
Preserve received material unchanged and create working views separately. Record origin and receipt time where reliable information is available. An internally assigned date does not automatically prove an external arrival time. The implementation should distinguish supplied information from metadata created within the organisation.
An unknown file should not be opened or processed without appropriate care simply because its extension looks suitable. Limit size and supported formats according to the operating need. Technical handling requires suitable controls for untrusted content. The simplified workflow here does not describe those implementation controls in full.
Receipt also needs an error path. Who sees an unreadable or incomplete transfer? How is a question raised and a replacement delivery related to the original case? A general log entry is insufficient when nobody subsequently knows whether an invoice still needs to be obtained or reviewed.
4. Identify the actual format and profile
An XRechnung and a hybrid invoice use different technical containers. The FeRD ZUGFeRD FAQ describes a hybrid format combining PDF/A-3 with embedded XML. The human-readable representation and structured information need to agree. An arbitrary PDF containing an arbitrary XML attachment does not automatically satisfy that description.
Identify the format actually used and any relevant profile. A product name alone is insufficient because profiles can cover different content and requirements. For controlled operation, record the combinations supported by the implementation and how it treats an unfamiliar combination rather than guessing from the supplier's terminology.
Keep identification, extraction and validation separate. Finding an embedded file establishes that content is present. Successfully parsing XML does not establish compliance with the required invoice standard. These stages therefore need distinct results rather than being collapsed into one reassuring green indicator.
Create a small format register during introduction. Include an appropriate valid sample, a deliberately invalid sample and the expected treatment of each. Do not place genuine business information into publicly accessible checking services merely for convenience. Where appropriate, perform the required check in a suitable environment under your organisation's control.
5. Validate with documented rules
The KoSIT Validator documentation describes XML Schema and Schematron checks together with separate configurations. Reproducible evidence therefore connects the tool, rule configuration and report. “Validation successful” is incomplete if nobody can later establish which rules were applied to the particular file.
Keep the report linked to the correct original. A later check using another configuration can produce another result. Do not silently overwrite the previous report. The history should make it possible to distinguish a changed file from a changed evaluation, particularly when resolving a disputed result.
A technical message needs an actionable explanation. An identifier for a validation rule may be difficult for accounting staff to understand. Relate it to a manageable task, such as a missing reference or unsuitable field value. Preserve the technical detail while giving the responsible person an understandable next action.
A successful format check supplies information to the next stage. It does not approve payment or confirm delivery of the service. Use deliberately different sample cases to verify that the application preserves this distinction. A technically valid but commercially unsuitable invoice must remain visibly subject to business review.
6. Map structured values to internal records
An external supplier number is not automatically the identifier used by your own system. Establish a justified mapping and treat unknown values separately. A similar name must not silently become a definitive match. Multiple locations and related companies make this especially important, since a name search alone can produce misleading results.
Order references, cost centres and owners may originate from different systems. For each target attribute, specify whether it is extracted from the invoice, supplemented from an internal register or decided by a person. This provenance helps explain conflicting values and prevents an automatically filled field from appearing more certain than it is.
A separate queue is useful for uncertain matches. It should state what is missing and who can resolve it. Automatically generated suggestions must remain distinguishable from confirmed assignments. A promising match probability does not automatically justify a binding accounting decision or a change to an authoritative record.
Test mapping with similar names and different identifiers. Examine changes to master data too. A new bank account or address can require its own verification. The invoice should not automatically overwrite every existing supplier detail merely because the incoming fields are technically readable and easy to transfer.
7. Investigate duplicates at more than one level
The same file can arrive repeatedly. Comparing bytes or checksums can help recognise identical content. The same invoice can also arrive in a different representation or through another route. A file comparison alone cannot establish that relationship, even when the underlying business transaction may be the same.
Define an appropriate business suspicion rule. Supplier mapping and invoice number may be relevant, but must fit the numbering scheme and transaction involved. Corrections and credit notes need understandable treatment as well. A matching amount or similar filename is not, on its own, a dependable definition of a duplicate invoice.
A suspicion initially requires investigation. Preserve both receipts and their relationship rather than automatically deleting one. The owner can determine whether the situation represents a resend, correction or genuinely different transaction. Record the outcome as part of further handling, so that the same uncertainty does not reappear at every retry.
The implementation also needs controlled retries. After a timeout, another attempt must not silently create two handovers or payment instructions. A suitable case identifier and explicit acknowledgement can help. This operational retry problem is distinct from deciding whether two different files represent the same business invoice.
8. Identify the next handling step explicitly
A small status record can expose the next unresolved task. The JavaScript below uses fixed teaching data. Each check is pending, passed or rejected; duplicate suspicion is recorded separately. The function prioritises work. It performs no accounting entry and is not a complete state machine for an invoice application.
function nextStep(receipt) {
const allowed = new Set(['pending', 'passed', 'rejected']);
const fields = ['format', 'matching', 'business', 'approval'];
if (!fields.every(field => allowed.has(receipt?.[field])) ||
typeof receipt?.duplicate !== 'boolean') {
throw new TypeError('Provide the complete review state.');
}
if (receipt.format !== 'passed') return 'Resolve format';
if (receipt.duplicate) return 'Investigate duplicate suspicion';
if (receipt.matching !== 'passed') return 'Resolve matching';
if (receipt.business === 'rejected') return 'Resolve business discrepancy';
if (receipt.business === 'pending') return 'Review substance';
if (receipt.approval === 'rejected') return 'Approval rejected';
if (receipt.approval === 'pending') return 'Obtain approval';
return 'Ready for handover';
}
const receipt = {
format: 'passed', duplicate: false, matching: 'passed',
business: 'pending', approval: 'pending'
};
console.log(nextStep(receipt)); // Review substanceThe fictional receipt remains in substantive review after passing format validation and matching. Handover becomes possible only after the business review and approval are complete. An explicitly rejected approval is not treated like one that has merely not happened yet. Unknown and incomplete states are rejected instead of being interpreted optimistically.
A real application additionally needs permissions, concurrent-edit handling, persistent storage and traceable changes. Arbitrary participants must not be able to mark a check as passed. This teaching function only makes the order of questions visible and prevents particular confusions in the example; it does not implement the surrounding responsibilities.
9. Record file integrity as supplementary evidence
A checksum can help determine whether the same bytes are still present. The Node.js Crypto documentation describes hash functions for this purpose. The small example below uses an invented text string solely for demonstration and explicitly does not process a valid invoice.
import { createHash } from 'node:crypto';
function fileHash(bytes) {
if (!Buffer.isBuffer(bytes) || bytes.length === 0) {
throw new TypeError('Non-empty file bytes are required.');
}
return createHash('sha256').update(bytes).digest('hex');
}
const bytes = Buffer.from('Fictional invoice receipt', 'utf8');
console.log(fileHash(bytes));Store such a checksum with the corresponding case reference and file. By itself it proves neither the issuer's identity nor business correctness or compliant retention. A useful control process connects several forms of evidence while preserving an understandable account of what each one establishes and what it leaves unresolved.
An identical hash is technical information about the examined content. A changed container holding the same business invoice data can have a different hash. File comparison and business duplicate investigation therefore perform different jobs and should not be given the same status label in the handling record.
10. Plan handover and retention together
Handover to accounting software needs an explicit acknowledgement. Which records were accepted, held or rejected? Sending a file successfully does not establish successful import. Preserve the relationship between the internal case, original file, validation reports and the outcome returned by the destination application.
Section 14b of the VAT Act contains invoice-retention requirements. Implementation must consider other applicable rules and the particular case. An additional readable view does not automatically replace the structured original information that must be retained. Agree storage, access and retrieval with the responsible specialists.
Try recovery using an appropriate sample set. Can the responsible person retrieve the invoice, related check and approval, and understand how they fit together? A directory containing many files is not yet useful evidence of a completed transaction. The relationship needs to remain understandable during a software transition too.
Consider different roles. Someone reviewing the substance of a document does not necessarily need every accounting function. Conversely, a necessary investigation should not fail because nobody can access the relevant information. Shape permissions around tasks and test them through the actual routes people need to use.
11. Start with a bounded pilot workflow
Select a manageable intake route with known owners. Include valid formats, errors, missing references, duplicate suspicion and rejected approvals. Agree expected results before running the cases. The pilot should examine transitions between stages, rather than merely demonstrate that one tool can display an invoice attractively.
Afterwards, review unresolved work and actual questions. A useful finding might be that uncertain supplier matches are now visibly assigned to a person. Do not convert that observation into a general savings percentage. A few cases can reveal specific weaknesses without supporting reliable claims about every future invoice.
Expand only after resolving the limits found in the trial. Existing Excel reports or business applications can remain when their roles are clearly described. The important improvement is a dependable end-to-end relationship between receipt and handling. A complete change of software is not automatically needed to achieve it.
12. Express pilot cases as verifiable decisions
A first case contains a formally suitable invoice without confirmed order matching. The expected task is to resolve that match. Record who supplies the reference and what information they need. Only then may the case advance. This checks whether missing internal information remains visible instead of being concealed by successful technical validation.
A second case has a known order but a line item rejected on business grounds. Handling must expose the discrepancy. Revalidating the unchanged file does not resolve that objection. Document how a question, correction or justified new decision is related to the case. Preserve the initial objection as part of the understandable history.
A third case is retried after an interrupted handover. Check whether acknowledgement already exists at the destination and how an uncertain state is investigated. The expectation is controlled resolution rather than an unchecked second import. This exercise tests a specific transition that normal-case demonstrations often leave invisible.
Checklist for a connected invoice workflow
- Review actual formats, business cases and the applicable legal context.
- Link receipt to an identifiable internal case.
- Preserve the original separately from working views.
- Document format, profile and rule configuration.
- Distinguish technical validation from business approval.
- Justify supplier, order and owner assignments.
- Examine file duplicates separately from business suspicion.
- Keep unclear and rejected cases visibly actionable.
- Handle retries and repeated handovers deliberately.
- Confirm acceptance in the destination application.
- Verify retention, retrieval and recovery.
Common questions about electronic-invoice workflows
Is a PDF sent by email sufficient?
An ordinary PDF without suitable structured invoice data does not become an electronic invoice in the statutory sense described here merely through its delivery route. Whether another invoice type is permitted in a particular case depends on the scope and applicable transitional provisions, among other factors.
Is a formally valid invoice automatically ready for payment?
No. Format validation addresses different questions from matching, substantive review and approval. This operating model therefore records their outcomes separately. A technically sound receipt can still lack an order reference or contain a discrepancy requiring business investigation.
Must all existing software be replaced?
Not automatically. First identify what already works dependably and where a concrete gap exists. A suitable intake, additional check or controlled interface may be enough. The full connected workflow then needs to be evaluated together rather than assuming that individually working components guarantee a sound process.
Does a file hash detect every duplicate invoice?
It helps compare identical file content. The same business transaction can appear in different files. A business suspicion rule and suitable treatment of corrections therefore remain necessary. A hash does not evaluate the underlying invoice or decide whether it should be paid.
Sources and next steps
Sources checked on 9 November 2026. The workflow, status model and source code are original teaching examples for collaboration between business owners and technical implementers.
