Food & Beverage Distributor Invoice Processing

Food and beverage distributor invoice processing is the workflow that turns supplier invoices, credit notes, delivery notes, and receiving records into structured AP data. Because the invoice doubles as the financial copy of receiving and traceability evidence, the extraction output has to capture line-level detail: pack size, unit of measure, quantity ordered versus delivered, catch or variable weight, lot or batch identifiers, and credit-note linkage back to the original invoice line. A header-only data set with invoice number, date, and total is not enough — the rest of the AP, inventory, and traceability work depends on the lines.

Distributor-side supplier-invoice handling is not the same job as buyer-side AP. A wholesale food and beverage distributor pays upstream suppliers and receives goods into inventory, so the invoice carries pricing, pack configuration, product identity, catch weights, lot codes, and delivery references that a buyer-side AP workflow may never need.

The broader generic-distributor view sits in wholesale distribution invoice processing. The buyer-side mirror, restaurants and foodservice operators extracting supplier invoices into a weekly purchase log, is covered in foodservice wholesaler invoice extraction to a weekly purchase log. This guide stays on the distributor-side schema and the exception patterns that come from food and beverage in particular.

Header and Line Fields the Extraction Has to Capture

The schema below starts from the four-document reality of distributor AP: supplier invoice, credit note, delivery note, and receiving record. Exceptions live in the gaps between them, so the extraction has to preserve the fields that connect them instead of stopping at invoice header data.

Header fields

The header carries the document-level facts that apply to the whole invoice.

Field	Notes
Supplier legal name	Match against the supplier master; legal name varies across invoices from the same supplier (covered later under supplier-name variation)
Supplier address	Required for traceability, addressed in the delivery and traceability section below
Supplier code	The distributor's internal supplier identifier where one exists
Supplier VAT or tax registration ID	Cross-border EU trade depends on this; useful as a tiebreak when legal name varies
Invoice number	Unique within the supplier; the credit-note linkage depends on it
Invoice date	Tax-point date for VAT, and the basis for payment terms
Payment due date	Driven by terms; either printed on the invoice or derived
Currency	Multi-currency suppliers are common in cross-border distribution
Payment terms	Net 30, 2/10 net 30, end-of-month, etc. — important for early-pay discount capture
Purchase order number	The reference back to the order that triggered the delivery
Delivery note number	The reference forward to the document the warehouse signed for
Supplier contact details	Useful when a query needs raising against a specific line

Line fields

The line is where distributor specificity lives. A header-only extraction loses everything the reviewer needs to verify receiving, reconcile catch weights, post inventory at the right cost, or trace a recall back to a specific batch. Line-level extraction, one row per invoice line, is the load-bearing capability.

Field	Notes
Product description	The supplier's wording, often differs from the distributor's internal item description
Supplier SKU or product code	The supplier's identifier; the bridge to the distributor's item master
Pack size with notation	6/10#, 4/1 GAL, 12x500ml, 24/12oz — packaging that defines the case
Unit of measure	Case, each, kilogram, litre, pound
Quantity ordered	From the PO, where the supplier prints it on the invoice
Quantity delivered or invoiced	What the supplier is billing for; should match the delivery note
Unit price	Price per unit of measure
Line discount	Promotional or contract discount applied at line level
Line total	Quantity × unit price less line discount, before tax
Catch or variable weight	Actual weight billed where the product is sold by case but priced by weight
Lot or batch identifier	Printed beside the line for traceable items, addressed in the delivery and traceability section
Production or pack date	Where present on the invoice rather than the case label
Expiry or use-by code	Required for perishables; sometimes a Julian date or BBE format
Line tax rate and amount	Held at line level where mixed rates apply, covered with the tax fields below
PO line reference	The link back to the specific line on the order, where the supplier provides it

Two of these fields deserve a closer look. Catch or variable weight is the field that distinguishes meat, fish, poultry, cheese, and produce billed by weight from goods billed by count alone. Where a case of beef is invoiced as one case but priced per kilogram against an actual catch weight, the line has to carry both — case count and catch weight — for the math to be reconcilable later. We treat this exception in depth in catch-weight invoice reconciliation; for the schema, the point is that the field has to be captured at extraction time, not derived after the fact.

Lot or batch identifier is the other field worth singling out. It's the field that turns the supplier invoice into a traceability record, and it sits on the invoice line — not in some separate document the AP team never sees. The traceability argument is developed below; what matters at the schema layer is that lot or batch is line-level data, captured against the same row as the product description and quantity.

Tax, Credit-Note, Freight, and Allowance Fields

Header and line fields cover the goods; three more field groups cover the rest of what distributor AP has to reconcile.

Tax fields

Food distribution is unusually rich in tax cases. A single supplier may bill at multiple rates within one invoice (chilled food at one VAT rate, alcohol or non-food at another), cross-border consignments may carry zero-rated intra-EU treatment, and imports from outside the EU come with their own documentation. The schema has to support all of it. For a country-specific workflow, see Portuguese food wholesaler supplier-invoice posting.

• Line-level tax rate and tax amount. Required wherever the invoice mixes rates. A header tax summary is not enough on its own — the line totals have to roll up to it.
• Invoice-level tax summary. The breakdown of taxable amount and tax per rate, plus the invoice grand total inclusive of tax.
• Supplier and customer VAT identifiers. Both required for intra-EU acquisitions; the buyer's VAT ID is what permits the supplier's zero-rate or reverse-charge treatment.
• Withholding tax fields. Where the jurisdiction or supplier contract applies them.
• Tax currency. Where the tax amount is stated in a currency different from the invoice currency, which happens on cross-border invoices that quote a local-tax amount alongside the foreign-currency total.

For extraction, the key point is simpler: capture line-level tax, invoice-level tax summaries, VAT or tax IDs, tax currency, and any withholding fields separately enough that mixed-rate and cross-border invoices can be reviewed without reopening the PDF.

Credit-note fields

Food distributor credit note reconciliation is one of the highest-value parts of the data model, because credit notes are where short deliveries, damaged goods, post-receipt price corrections, and rebates land. A credit note that floats free of its trigger is a credit note someone has to chase. The fields that prevent that:

• Reason code. Return, price correction, damaged goods, short delivery, rebate application, post-receipt adjustment. Some suppliers print a structured reason code; others print free-text the extraction has to classify.
• Original invoice number. The reference back to the invoice the credit is correcting.
• Original invoice line reference. Where the issue is line-specific — which it usually is for short delivery, damage, or substitution — the reference to the specific line.
• Signed quantity and signed amount. Credits run negative; the schema has to carry the sign rather than infer it from document type alone.
• Linkage to the originating exception. Whether the credit was triggered by a receiving discrepancy, a chargeback, or a contract rebate.

That last field — the linkage back to the trigger — is where rebate and allowance credits often disappear. A supplier may issue a credit for a volume rebate, a promotional allowance, a slotting fee, or a chargeback against a specific supplier failure; without the linkage, the AP team cannot tell which is which, and the controllership view of supplier performance loses visibility into the pattern. We treat the broader pattern in vendor chargeback management for wholesale distributors; for the schema, capturing reason code and original-line reference at extraction time is what makes the chargeback discipline possible.

Freight, surcharge, rebate, and allowance lines

These lines belong on the schema but separate from product lines, because their cost-allocation treatment is different.

• Line type. Product, freight, surcharge, rebate, allowance, tax adjustment. The single most important non-product field, because it determines how the line gets posted.
• Freight or surcharge amount. Often a single header-level line on the invoice, sometimes itemised by service (transport, fuel adder, temperature-controlled handling, lift-gate, delivery window).
• Cost-allocation method. Where the supplier provides it — flat freight charge, allocated by weight, allocated by value, or allocated by line. Imports from non-EU suppliers usually require freight, duty, and customs charges to be allocated across the line items as landed cost; the supplier invoice is one input into that calculation, but it isn't the whole of it. The deeper treatment is in landed cost accounting for distributors.
• Account code or category. Where the distributor has set a separate GL account for freight or for promotional allowances, the field that drives the posting.
• Reference to the qualifying invoices. For rebates and allowances applied across a range of prior invoices, the reference to that range — without it, the rebate is unallocated cash with no visible basis.

Freight is the most common reconciliation point inside this group. A fuel surcharge can change between quote and invoice; a temperature-controlled adder may appear on some deliveries and not others; a flat freight charge may not match the contracted rate. The schema fields above are what make each of those reviewable rather than swallowed into the invoice total.

Delivery and Traceability as the Invoice's Second Job

The same supplier invoice that documents the payable is also, in practice, the document the distributor will rely on if it needs to trace what was bought, from whom, and when. That dual role is the reason the schema reaches beyond financial fields.

Delivery cross-reference fields

The fields that connect the invoice to the supplier's and the distributor's record of physical movement:

• Delivery note number as printed on the invoice.
• Delivery date as recorded by the supplier.
• Receipt date as logged by the warehouse on the distributor's receiving record.
• Line-level linkage between an invoice line and the corresponding delivery-note line, where the supplier numbers its delivery-note lines.

Captured at extraction time, these fields turn food distributor delivery note invoice matching into a structured operation. The match runs across three documents — invoice line, delivery-note line, receiving-record line — and the schema fields above are what allow it to run by computation rather than by manual cross-reference.

Lot, batch, and date-code fields

Lot or batch identifiers appear on supplier invoices wherever the product is perishable, regulated, or subject to a recall pathway: dairy and meat almost always, produce often, branded canned goods variably, alcohol and beverages where the producer ties production runs to lot codes for quality control. The extraction should capture these where they appear: at the line level, beside the product description and quantity they apply to. The fields the schema needs:

• Lot or batch number as printed.
• Production or pack date where the supplier prints it on the invoice rather than only on the case label.
• Expiry, use-by, or best-before date code. Often a Julian date, a structured BBE format, or a country-specific notation.

The practical payoff is traceability. When a recall is issued by the supplier, a regulator, or the distributor's own customer, the AP record already carries the lot identity. The UK Food Standards Agency guidance on Regulation 178/2002 says minimum traceability records should include the customer or supplier address, the nature and quantity of products, and the transaction and delivery dates, and notes that this information is already standard in basic accounting. A distributor that extracts only header totals still has to log those fields somewhere else; a distributor whose AP data carries them on every line gets the traceability record as a by-product of the AP work.

Where Each Field Earns Its Place: The Exception Patterns

The schema earns its complexity in recurring AP exceptions:

Pack-size change between order and invoice. A switch from 6/10# to 4/10# or from 12x500ml to 24x330ml looks like a quantity and price mismatch unless pack size, unit of measure, PO number, and PO-line reference are captured at line level.

Short delivery. When invoiced quantity exceeds quantity received, the resolving fields are quantity ordered, quantity delivered, quantity received, delivery-note reference, credit-note reason code, and signed credit quantity.

Substitution. When the supplier ships a different product than ordered, the resolving fields are supplier SKU, product description, pack size, unit of measure, and PO-line reference.

Damaged-goods credit. When a portion of a delivery is rejected, the resolving fields are damaged-goods reason code, original invoice number and line reference, signed quantity, signed amount, and lot or batch identifier where disposal, complaint, or insurance review needs traceability.

Catch-weight variance. When invoiced weight does not match nominal case weight or delivery-note weight, the resolving fields are catch weight, case count, unit price per kilogram or pound, and delivery-note weight cross-reference.

Rebate or allowance application. For volume rebates, promotional allowances, slotting fees, or marketing co-ops, the resolving fields are line type, qualifying invoice or invoice range, cost-allocation method, and account code.

Freight and surcharge reconciliation. When freight does not match the contracted rate or a fuel surcharge appears without notice, the resolving fields are line type, freight or surcharge amount, stated basis for the charge, and supplier notes.

Supplier-name variation and multilingual invoice text. When the same supplier appears under different legal names or languages, the resolving fields are supplier VAT or tax registration ID, internal supplier code, and legal name as printed. Consolidation by VAT ID keeps the supplier stable even when the visible name changes.

From Structured Extraction to AP Review and ERP

Most food and beverage distributor AP teams still work in Excel and a separate ERP rather than in a single integrated system. The realistic path is review-first, post-second: extract the supplier invoices into a spreadsheet shaped around the schema this article describes, review the variances in Excel, then import the reviewed data into the ERP. Food distributor AP automation, in practice, means giving the team that workflow rather than promising a touchless pipeline that doesn't fit how distributor AP actually runs.

In the spreadsheet, the work is structural. Quantity ordered, quantity delivered, and quantity received sit in adjacent columns and a sort surfaces the deliveries that don't match. Credit-note reason codes and original-invoice references make rebates and damage credits filterable rather than scattered. Multilingual supplier names roll up by VAT ID so the same supplier appears once, not three times. Catch weights sit beside case counts so unit-price-by-weight reconciles against billed weight.

The output formats each fit a different next step. Excel (.xlsx) is what most AP teams actually open for review and adjustment — native numeric and date typing, sortable columns, pivot-able for supplier-level views. CSV is what ERP import templates usually consume, with column mappings the ERP administrator has already defined. JSON is what an API integration or a middleware layer consumes when the team is automating posting rather than importing files by hand. The same extraction can deliver any of the three from the same source documents.

When the team is ready for the ERP step, the standardised schema pays off. Pack size and unit of measure at the line level, line-level tax, credit-note linkage to the original invoice, lot or batch on the line, and a delivery-note reference at the header give the import a clean shape to map to — whether the destination is SAP, Oracle NetSuite, Microsoft Dynamics, Sage, or a distributor-specific food and beverage ERP. Imports become a mapping exercise rather than a remediation exercise; the ERP receives reviewed, structured data rather than having to figure out a non-standard invoice.

This is the operational place for structured supplier invoice extraction to do its job: take a batch of supplier invoices, credit notes, and delivery documents — PDFs, scans, or images, in any of the languages cross-border EU suppliers actually use — and convert them into the schema this article has published, in Excel, CSV, or JSON, with the fields the AP team names at prompt time. The schema is written once as a prompt, saved for reuse against the next batch, and the structured output is reviewed in whichever format the team's next step expects.

For teams ready to embed extraction in their own pipeline rather than working from the web app, the invoice extraction API and the Python and Node SDKs make the same capability available as a building block.