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.
The first thing worth saying out loud is the one most vendor pages leave unsaid: distributor-side supplier-invoice handling is not the same job as buyer-side AP. A wholesale food and beverage distributor is paying upstream suppliers (growers, processors, importers, branded manufacturers) and receiving goods into inventory. The supplier invoice it processes carries pricing, pack configuration, product identity, catch weights, lot codes, and delivery references — data the distributor needs because it will resell those goods and may be asked to trace them. A restaurant or grocery buyer can simplify most of that away; a distributor cannot.
That difference is concrete. A supplier invoice into a wholesale distributor commonly shows pack notation like 6/10# (six ten-pound cans per case) or 4/1 GAL (four one-gallon containers per case), individual catch weights on cases of meat, fish, or cheese, lot numbers printed beside the line item, and a delivery-note number that links the document back to the warehouse receipt. None of that is incidental. Each field maps to a downstream task — inventory posting, margin calculation, recall response, credit-note reconciliation — that an AP team has to be able to support from the same data set.
This article is the food-and-beverage specific treatment of distributor AP. The broader generic-distributor view sits in our piece on wholesale distribution invoice processing; what's here is the schema and the exception patterns that come from food and beverage in particular. The buyer-side mirror — restaurants and foodservice operators extracting their supplier invoices into a weekly purchase log — is a different workflow with a different data model, covered in foodservice wholesaler invoice extraction to a weekly purchase log. The rest of this guide stays on the distributor side throughout.
How the Supplier Invoice, Credit Note, Delivery Note, and Receiving Record Relate
Distributor AP doesn't work from one document; it works from four, and supplier invoice processing for food distributors has to span all of them.
The supplier invoice is the financial obligation. It carries product description, supplier SKU, pack size, unit of measure, quantity, unit price, line total, tax, and — in food and beverage especially — often the lot or batch identifier and a reference to the delivery note that should match it. The invoice is what the AP team is being asked to pay against, but it is also the document that aggregates the most fields.
The credit note is a correction or reversal. It exists because something on a prior invoice was wrong: a short delivery, a damaged consignment, a price adjustment, a rebate that posts after the fact. A useful credit note references the original invoice number and, where the issue is line-specific, the original line. Signed quantities and signed amounts make it clear which way the adjustment runs. Without that linkage the credit floats free of its trigger and AP has to reconstruct the connection by hand.
The delivery note, or proof of delivery, is the supplier's record of what was shipped or what arrived at the dock. It carries ordered-versus-delivered quantities and, where catch weights apply, the actual weight per case as recorded at dispatch or on the truck. The invoice will quote the delivery-note number; the delivery note will quote the supplier's order number. Together they form the supplier's two-document view of the transaction.
The receiving record is the distributor's own log of what the warehouse actually accepted. It's where short deliveries get noted, where damaged cases get rejected, where substitutions are flagged, and where catch weights get re-weighed and reconciled against the delivery note. Each of these four documents has a job, but they only do that job collectively — the credit note depends on the original invoice line, the delivery note carries quantities the invoice has to match, and the receiving record exposes the gaps either of the supplier-side documents missed.
The operational point this article keeps returning to is the consequence of all that: the exceptions live in the gaps between these documents. A pack-size change shows up as a mismatch between the purchase order and the invoice. A short delivery shows up between the invoice and the receiving record. A damaged-goods credit shows up later as a credit note that should reference the original invoice line but often doesn't. A catch-weight variance shows up between the invoice's billed weight and the delivery note's actual weight. None of these exceptions are visible in any one document alone. That is why a data model designed to handle distributor AP has to capture fields from across all four — and why a schema built around just the supplier invoice header will keep losing them.
Header and Line Fields the Extraction Has to Capture
The schema below is what an AP team in a wholesale food and beverage distributor actually needs from each supplier invoice. It is published as fields, not as a description of "header information" or "line details", because at the operational level only specific named fields are usable for review, posting, and reconciliation.
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 for food distributor invoice line item extraction.
| 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.
- 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.
The cross-border pattern matters operationally. Intra-EU acquisitions from one EU country to another typically arrive zero-rated on the supplier invoice, with the buyer accounting for the acquisition VAT under the reverse charge — only viable if both VAT IDs are captured. Imports from non-EU suppliers arrive without VAT on the supplier invoice; the VAT lands separately via the import-VAT document from the customs agent or postponed-VAT scheme, which the AP team has to reconcile against the supplier invoice but is not itself part of the supplier invoice schema.
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. Food distributor lot number invoice extraction is the operation that captures 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 concrete. When a recall is issued — by the supplier, by a regulator, or by the distributor's own customer — the AP record already carries the lot identity. The distributor does not have to reconstruct which delivery, which invoice, and which line contained the affected product; the data is on the row.
The traceability argument
The reason this section sits at the centre of the article rather than at the edge is that the supplier invoice, properly extracted, is the traceability record. The UK Food Standards Agency guidance on Regulation 178/2002 is explicit on this: minimum traceability records for food businesses should include the address of the customer or supplier, the nature and quantity of products, and the date of the transaction and delivery — and the Agency notes that this information is already standard practice in basic accounting. That is the supplier invoice.
What changes between distributors that have to maintain a parallel traceability log and distributors that don't is not the regulation; it's whether the AP data model captures the line-level fields. A distributor that extracts only header totals will still need to log lot, batch, supplier address, and delivery date somewhere else to satisfy the requirement. A distributor whose AP data carries those fields on every line gets the traceability record as a by-product of the AP work it was already doing. The schema decision sits upstream of the compliance question.
This is not a compliance walkthrough — the regulation has its own depth that is outside the scope of an invoice-processing guide. The argument here is narrower and operational: design the supplier invoice extraction around the fields that AP and traceability share, and the same data set serves both.
Where Each Field Earns Its Place: The Exception Patterns
The schema above earns its complexity in the exceptions. Below are the recurring exception patterns in food and beverage distributor AP, with the fields that have to be captured cleanly for each to be reviewable.
Pack-size change between order and invoice. Without pack size and unit of measure captured at the line level on both the PO and the invoice, a switch from 6/10# to 4/10# or from 12x500ml to 24x330ml shows up to the reviewer as a quantity and price that simply don't match — and the only way to find out why is to open the source document. With pack size as a captured field and the PO and PO-line reference at the header and line, the reconciliation is visible without the dig.
Short delivery. When the invoiced quantity exceeds the quantity actually received, the reconciliation has to align three numbers: quantity ordered, quantity delivered (on the invoice and the delivery note), and quantity received (on the receiving record). The delivery-note reference at the header is what lets the three documents line up at all. When the supplier issues the correction, a credit-note reason code of short delivery and a signed quantity close the loop.
Substitution. The supplier ships a different product than ordered — same category, different SKU. Both identifiers matter: the SKU is the database key, but the description may be the only field that flags the substitute clearly when the supplier reuses an SKU pattern across variants. Pack size, unit of measure, and PO-line reference complete the comparison.
Damaged-goods credit. A portion of a delivery is rejected on inspection. Resolving fields: credit-note reason code (damaged goods), original invoice number and line reference, signed quantity, signed amount, and — where the damaged goods have to be traced for disposal, supplier complaint, or insurance — the lot or batch identifier. The trail runs from receiving record (where the damage was noted) to credit note (where it was financially resolved) to lot field (where it was traceability-identified), and the schema has to support all three crossings.
Catch-weight variance. The invoiced weight does not match either the case count's nominal weight or the delivery-note's actual weight. Resolving fields: catch or variable weight at the line level, quantity (the case count), unit price per kilogram or pound, and the delivery-note weight cross-reference. Variance review depends on both the invoice's billed weight and the delivery note's weighed-at-dispatch figure being captured against the same line key.
Rebate or allowance application. A supplier applies a volume rebate, a promotional allowance, a slotting fee, or a marketing co-op against either the current invoice or a range of prior invoices. Resolving fields: line type (rebate or allowance), the reference to the qualifying invoice or invoice range, the cost-allocation method (across lines, against a specific account, or treated as deferred income), and the account code where the distributor wants the credit posted. Rebates that arrive as standalone credit notes without an invoice reference are the single largest source of AP cleanup work in some distributors.
Freight and surcharge reconciliation. The freight line on the invoice does not match the contracted rate, or a fuel surcharge appears without prior notice. The reconciliation runs against the freight contract or quoted rate, which sits outside the invoice — the schema's job is to make the invoice side computable. Line type, freight or surcharge amount, the basis the supplier states for the charge (rate per case, per pound, per pallet, or flat), and the supplier-side narrative or notes where the basis is recorded are what makes the rest of the work possible.
Supplier-name variation and multilingual invoice text. The same supplier appears under slightly different legal names across invoices — full trading name, parent entity, regional subsidiary, or a translated form of the same name. On cross-border EU consignments, the invoice itself may be in French, German, Spanish, Italian, Dutch, or another language the AP team doesn't read fluently. Food distributor multilingual supplier invoice processing has to handle both at once. Resolving fields: supplier VAT or tax registration ID (the most stable identifier across name variations), supplier code (the distributor's internal identifier), and the legal name as printed. Consolidation by VAT ID lets the AP team treat the supplier as one entity even when the printed name varies, and an extraction that reads the supplier-language invoice produces the same structured English-named fields the reviewer is working in.
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 review work is concrete because the data is concrete; the schema is what makes that possible.
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 REST API and the Python and Node SDKs make the same capability available as a building block.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.
Related Articles
Explore adjacent guides and reference articles on this topic.
Wholesale Distribution Invoice Processing: Challenges and Fixes
Wholesale distributor AP teams face supplier invoices with freight, allowances, and partial receipts. This guide shows where structured automation helps.
Extract Apparel Wholesale Invoices to Excel in India
Convert Indian apparel wholesale GST invoices into Excel without losing size-wise quantities, HSN, rates, tax splits, and GSTR-1-ready line items.
Steel Supplier Invoice MTR Packet Reconciliation
Build a steel supplier invoice packet spreadsheet that ties invoice lines to POs, packing slips, receiving records, heat numbers, MTRs, and exceptions.