Delivery Note Invoice Matching: AP Workflow Guide

Delivery note invoice matching is a receipt-based invoice verification control used when AP needs evidence of what was actually delivered before payment is released. Instead of relying only on the purchase order and supplier invoice, the team compares the invoice with the delivery note, proof of delivery, or goods receipt record for reference numbers, item descriptions, quantities, dates, and receiving confirmation. Manual review usually starts when deliveries are partial, shipments arrive in stages, receipt references are missing, or billed quantities do not match what the receiver acknowledged.

That distinction matters in any operation that buys physical goods. A purchase order shows what was supposed to arrive. It does not prove that the warehouse received the right quantity, at the right site, on the right date, in a condition that supports payment. If your team needs to match invoice to delivery note evidence before approval, the real control question is whether the invoice reflects receipt reality, not just ordering intent.

This is also why delivery note invoice matching should not be treated as another general explainer about shipping documents. AP cares about the delivery note and the proof of delivery because they anchor payment to receiving evidence. When that evidence is incomplete, AP, warehouse receiving, and procurement can end up arguing over the same invoice from different angles. The rest of the workflow is about preventing that handoff problem from turning into a blocked-invoice backlog.

Why Delivery Evidence Changes the Matching Rule

Most teams learn invoice matching as a 2-way or 3-way control. In the standard model, the purchase order sets the commercial expectation and the invoice must line up with that expectation. But once physical receipt becomes the real risk point, you move from order validation to goods receipt invoice verification.

The difference is practical. PO-only matching works when the supplier relationship is stable and the risk of receipt disputes is low. Standard three-way matching adds receiving evidence, but many teams still treat the goods receipt as a binary posted or not-posted signal. Delivery-note-based verification goes further. It asks whether the invoice reflects the same receipt event shown on the delivery note, the proof of delivery, or the warehouse posting itself. In other words, invoice verification against delivery notes is the control you add when receipt evidence matters more than PO status alone.

This is where the broader 2-way, 3-way, and 4-way matching framework still matters. That framework explains the control family. What it does not solve on its own is the messier question of how to approve an invoice when one shipment becomes several deliveries, or when the supplier invoice references receipt documents more clearly than the purchase order does.

A goods received note, or GRN, is often the strongest internal confirmation that stock was booked into inventory. If you need a refresher on how goods received notes support receiving-based verification, treat it as the warehouse-side record that complements external documents such as a delivery note or packing slip. Proof of delivery invoice matching usually sits on top of that same logic: the carrier or supplier confirms handoff, the receiver confirms what was accepted, and AP decides whether those records justify payment.

The Fields That Must Line Up Across the Invoice and Delivery Record

A reliable receipt-based review starts with a small set of fields that must be compared consistently. Teams get into trouble when they chase every visible data point instead of defining which fields drive approval. If you need background on what a delivery note includes and how receivers use it, keep that separate from the AP checklist below. AP is not reviewing the form for completeness. It is checking whether the invoice can be tied to a real, accepted delivery.

For header-level review, compare:

• supplier name or account identifier
• purchase order number, if the supplier and ERP use one
• delivery note or proof of delivery reference
• delivery date and invoice date
• ship-to site, warehouse, or receiving location

For line-level review, compare:

• item code or item description
• unit of measure
• delivered quantity versus billed quantity
• any backorder or short-ship notation
• receiving status, such as accepted, partially received, or rejected

Some fields should match exactly. Document references, site identifiers, and totals tied to a single receipt event usually fall into that category. Others can be normalized. A supplier may abbreviate a product description while the warehouse uses a full item name, or the carrier may format the same reference with spaces or hyphens. That is still matchable if your team has a standard rule for interpreting equivalent values.

The real risk appears when inconsistent labels hide a real mismatch. A delivery note reference buried in a free-text field, or a quantity stated in cases on one document and units on another, forces AP into manual detective work. Receipt-based control gets stronger when the team defines the minimum required matching fields before the invoice ever reaches approval.

---

How to Match Partial Deliveries, Split Shipments, and One Invoice Covering Multiple Receipts

This is where generic matching guides stop being useful. Real receiving activity rarely follows the neat one-order, one-delivery, one-invoice pattern.

For partial delivery invoice matching, start by separating what has been received from what has been ordered. If the supplier bills the full purchase order before the final receipt exists, AP should compare billed lines only against the quantity that the warehouse has already accepted. If the commercial terms allow partial billing, approve only the received portion or request a corrected invoice. If the supplier terms require full delivery before billing, hold the invoice until the final receipt is posted.

Split shipments need one more step: quantity aggregation. A single order line may arrive across two or three delivery notes, each with its own proof of delivery and receiving timestamp. In that case, the reviewer should sum accepted quantities across the relevant receipts before comparing them to the invoice line. What matters is not whether each delivery note matches the invoice by itself, but whether the combined receipt evidence supports the billed amount.

The one invoice multiple delivery notes scenario is common with weekly or monthly consolidated invoices. AP should require the invoice to point to every included receipt reference, then reconcile each billed line to the underlying delivery events. If some deliveries are confirmed and others are still disputed, the team needs a clear policy:

• approve only the lines backed by accepted receipts
• hold the full invoice if the supplier contract requires complete shipment support
• ask for a credit and rebill when references cannot be separated cleanly

Date mismatches also matter. A quantity may be correct in total but tied to the wrong delivery window or receiving location. That can signal duplicate billing, a substitute shipment, or a receipt posted to the wrong site. Proof of delivery invoice approval should follow the same logic. Carrier confirmation is useful evidence, but it should not override a warehouse record showing short receipt, rejected goods, or an unresolved discrepancy.

The Exceptions That Should Trigger an Invoice Block

A delivery-based control only works if the team defines which mismatches can be normalized and which ones must stop approval. Without that line, AP either over-blocks routine issues or pays invoices before receipt evidence is reliable.

The following exceptions usually justify manual review or an invoice block:

• no delivery note, proof of delivery, or GRN reference that can be tied to the invoice
• billed quantity exceeds accepted quantity
• substitute items were delivered but the invoice still reflects the original ordered item
• the same receipt reference appears to support more than one invoice
• delivery dates conflict with the receiving log or the invoice predates any confirmed receipt
• the carrier shows delivery complete, but the warehouse record is still partial, rejected, or disputed

Some issues are administrative. A reference might be present but formatted differently, or a receiving post may lag by a few hours. Those can often be cleared through normalization or short-cycle follow-up. Others point to genuine evidence gaps and need escalation.

In practice, proof of delivery invoice approval should be conditional, not automatic. APQC benchmark on electronic proof of delivery reports a median of 80.0% of deliveries with electronic proof of delivery across its cross-industry benchmark sample. Even in environments with broad POD coverage, AP still needs a policy for missing references, quantity variances, and receiving disputes.

A good exception rule asks one question: does the current document set prove what was accepted for payment? If the answer is no, the invoice should stay out of the approved queue until the missing evidence is attached or the supplier corrects the bill.

---

Who Resolves Delivery-Based Mismatches and What Each Team Owns

Blocked invoices linger when everyone can see the mismatch but nobody owns the next action. Delivery-based matching works best when the case record makes ownership explicit.

AP should own document completeness and financial reasonableness. That means checking whether the invoice can be tied to the right supplier, order, receipt reference, quantity, and amount before it is routed for approval. AP should not be guessing whether 18 units actually reached the dock.

Warehouse receiving should own the factual receipt record. The receiving team confirms what arrived, what was short, what was damaged, and whether the delivery note or proof of delivery matches the physical handoff. If the receiving acknowledgment is incomplete, AP needs that team to update the record before payment proceeds.

Procurement should own supplier resolution. When the invoice references the wrong delivery note, includes substitute items, or bills goods the warehouse never accepted, procurement is usually the function with the leverage to request a corrected invoice, revised shipping document, or credit note.

The supporting evidence should travel with the exception: receiving comments, POD files, supplier correspondence, and the relevant line-level comparison. Whether your team works in SAP Ariba, Microsoft Dynamics 365, or a lighter approval tool, the principle is the same. Each blocked invoice needs one accountable owner, one documented reason, and one next step. That prevents delivery-note mismatches from aging into a silent backlog.

How Structured Extraction Reduces Receipt-Based Exception Chasing

The hardest part of invoice verification against delivery notes is usually not the control logic. It is the manual cleanup work around inconsistent references, mixed file formats, and line items that have to be compared across several documents.

That is where structured extraction helps. When teams use invoice data extraction software for delivery-note matching, the practical win is a cleaner review set: invoice numbers, purchase order numbers, receipt references, dates, quantities, totals, and line details can be extracted into a consistent Excel, CSV, or JSON file instead of being retyped from PDFs. In Invoice Data Extraction, users can upload PDF, JPG, and PNG files, tell the system exactly which fields to extract, and download structured output with source file and page number references for verification. That makes it easier to normalize reference formats, flag missing values, and send only true exceptions for human review.

This is especially useful when supplier invoices, carrier documents, and warehouse records describe the same event differently. One file may show a proof of delivery number, another a delivery note reference, and a third only a free-text receiving comment. If the team standardizes which fields matter, the comparison becomes faster and more defensible.

The same pattern shows up outside goods receiving. If your support-document approvals extend into services, a similar support-document approval workflow for service invoices follows the same principle: extract the evidence fields first, then review only the exceptions that actually need judgment.

A practical rollout does not need to start with full automation. Start by defining the required matching fields, the normalization rules for references and dates, and the exception reasons that should block payment. Then use structured extraction to surface those fields consistently so AP can spend time resolving real mismatches, not rebuilding the document trail by hand.