Invoice approval workflow: from incoming invoice to approved without the email chain

An invoice approval workflow decides who confirms that a supplier invoice is correct before it is booked and paid, and how that decision is recorded. A good one routes each invoice to the person who owns the budget, applies limits automatically, handles absences, and stores the approval with the invoice. An email chain does none of this reliably, which is why invoices go missing and discounts expire.

Most companies try to fix approval with invoice processing automation that sends reminders. The real problem usually sits earlier: nobody has written down who approves what. Once the rules exist, the routing is the easy part.

---

Why does invoice approval by email break down?

The pattern is familiar. An invoice arrives in a shared inbox. Someone in accounting forwards it to the person who probably ordered it, asking "is this ok?". That person is travelling, forwards it to a colleague, who replies "yes, I think so" two weeks later. Meanwhile the supplier sends a reminder, and the reminder arrives as a second invoice.

Four things go wrong in that chain.

The routing is a guess. Accounting has to know who ordered what. For a recurring software subscription that is obvious. For a one-off consulting invoice with a vague description, it is not.

The check is undefined. "Is this ok?" can mean anything. The approver may confirm that the service was delivered, but nobody confirms the price matches the offer, the quantity matches the delivery, or the invoice meets the formal requirements.

Absences stop everything. An invoice waiting in one person's inbox is invisible to everyone else. If that person is on holiday for three weeks, so is the invoice.

The record is scattered. Under the German bookkeeping rules (GoBD), every booking must be traceable from the document to the entry. An approval that lives in someone's mailbox is hard to produce when the tax auditor asks who released a payment and why. Booking documents must be kept for eight years since the Fourth Bureaucracy Relief Act took effect in 2025, and finding a two-line email from 2026 in 2033 is not a plan.

The wider accounts payable process, from capture to payment, is covered in our article on accounts payable automation. This article is about the approval step itself, and how to design it so it does not need chasing.

What does the approver actually confirm?

German practice separates two checks, and it helps to name them because they belong to different people.

The factual check (sachliche Prüfung) confirms that the company ordered the goods or service, received it, and at the agreed price and quantity. Only someone close to the purchase can do this: the team lead who booked the contractor, the warehouse that received the delivery.

The arithmetic and formal check (rechnerische Prüfung) confirms that the totals add up, the VAT is calculated correctly, and the invoice contains what the VAT Act requires, such as the supplier's tax number or VAT ID, the delivery date and the VAT amount per rate. This belongs in accounting, or in the system.

An approval workflow works when each person checks only what they can judge. Asking a marketing lead to verify the VAT rate wastes their time and adds no control. Asking accounting to confirm that a workshop actually took place is a guess.

For invoices linked to a purchase order, much of the factual check can be done by comparing invoice, order and delivery, which is the subject of the three-way match. The approver then only sees the invoices where something does not match.

Who should approve which invoice?

The simplest durable rule is: the person responsible for the cost centre approves invoices booked to it. Cost centre owners already manage the budget, so they are the people who know whether a cost was expected.

On top of that, most companies need three more rules:

• Amount limits. Up to a set amount, the cost centre owner approves alone. Above it, a second person approves, usually the department head or a managing director (Geschäftsführer). Write the limits down and review them yearly.
• Ordered versus unordered invoices. An invoice that matches an approved purchase order within a small tolerance may need no further approval. An invoice without an order always goes to the cost centre owner.
• Recurring contracts. Rent, leases and subscriptions can be approved once at contract level, with the monthly invoice checked only for changes in amount.

Two control rules apply on every path. The person who approves an invoice should not be the person who releases the payment, and nobody approves an invoice addressed to themselves or their own expenses. These are the same separations an auditor will look for.

If purchase requests and orders are not in the same system, approval starts too late, at the invoice. The full chain from request to payment is described in our guide to procure-to-pay.

How do you handle absences, escalations and deadlines?

Rules for the normal case are easy. The workflow is tested by the exceptions.

Deputies. Every approver names a deputy, and invoices move to the deputy automatically after a set number of days, or immediately when the approver is marked absent.

Escalation. An invoice that is neither approved nor rejected after a fixed period goes to the next level. This keeps the queue visible instead of quietly ageing.

Due dates and discounts. The approval deadline should follow the payment terms, not the order in which invoices arrived. An invoice with a cash discount (Skonto) for payment within ten days needs approval in days, not weeks. When paying early is worth it is covered in payment terms and Skonto.

Rejections. A rejected invoice needs a reason and a next step: request a credit note, ask for a corrected invoice, or clarify with the supplier. "Rejected" with no comment just restarts the email chain.

What must the approval record contain for GoBD?

An approval is part of the booking record, so it has to meet the same standard as the booking. In practice, that means you can show for every invoice who approved it, when, in which role, and with which comment. The record must not be changeable afterwards, and it must be stored with the invoice, not in a separate tool that may be switched off in three years.

For e-invoices, the structured XML is the original document. The BMF letter of 14 July 2025 on GoBD confirms that storing the structured part is generally enough, but booking notes or other tax-relevant information added to the readable part must also be kept. Approval notes are exactly that kind of information, which is a good reason to keep them in the system rather than on a printed copy. The storage side is explained in archiving invoices under GoBD.

How does Agent F help you approve invoices without the email chain?

In Agent F, an incoming invoice, whether a PDF or an XRechnung, is captured when it arrives. Where there is a purchase order, Agent F compares invoice, order and goods receipt in a three-way match and flags differences.

It then suggests the account, cost centre and VAT treatment from your own booking history, each with a confidence score. The invoice follows the approval workflow you define, so nobody has to forward it by email or guess who ordered it.

Nothing is booked or paid without a person's approval. Every step, from the suggestion to the approval and any correction, is stored in an immutable audit trail with the invoice. Approved invoices are booked to the general ledger on SKR04 or your own chart of accounts and flow into the DATEV export for your tax advisor (Steuerberater) without retyping.

To start, write down your cost centres and their owners, set two or three amount limits, and name a deputy for every approver. Then take last month's invoices and check how many could have been routed by those rules alone. The ones that could not show you where the rules are still missing.

Learn how Agent F works, or see it on your own invoices at agent-f.ai/demo.