Skip to main content
Co-packer invoice reconciliation: daily templates, acceptable variances and escalation ladders

Co-packer invoice reconciliation: daily templates, acceptable variances and escalation ladders

How craft breweries can catch case and pallet discrepancies before they turn into thousands in silent overbilling

The math on a co-packing invoice almost never matches your production sheet perfectly. A case here, half a pallet there, a variance clause buried in the contract that nobody on your team actually reads before approving the AP batch. On its own each gap looks like rounding noise. Stacked across a year of runs, it's real money walking out the door — and most breweries never catch it because reconciliation happens weeks after the run, if it happens at all.

This is a piece about the boring, specific work of matching what you shipped in and contracted for against what you got invoiced for on co-packed beverage runs. Cases, pallet counts, contracted variance rules, and what to do when the numbers don't line up. It's narrow on purpose.

Why co-packer invoices drift from reality

Start with how a run actually flows, because the drift is baked into the process.

You send raw materials — cans, ends, cartons, trays, maybe your own liquid if it's a straight pack. The co-packer runs the line, and yield is never 100%. Cans get crushed on the depalletizer, seams fail, fill-height rejects pile up, and the last partial layer of a pallet gets counted "close enough" by whoever was on shift. Then the invoice gets built from their count, on their system, using their rounding conventions.

The gap between your expected good cases and their billed good cases comes from a handful of predictable places:

  1. Spoilage and reject allowances that were agreed verbally but never nailed down in writing
  2. Full-pallet vs. mixed-pallet counting — a pallet spec of 60 cases that ships as 54 gets billed as a full pallet anyway
  3. Material shrink — you sent 20,160 cans, they report using 19,940 to make your target, and nobody reconciles the 220-can gap
  4. Changeover waste billed to your run instead of absorbed, especially when your SKU followed someone else's on the same line
  5. Rate tiers — the per-case rate assumed a minimum run size you didn't quite hit, so a surcharge appears that you weren't expecting

None of these are fraud. Most are just a busy co-packer running thin margins and defaulting to counts that favor them slightly. The problem is that "slightly" compounds.

What the drift actually costs

A typical example: a regional brewery running four co-packed SKUs, roughly two runs a month, averaging around 1,800 cases per run. Their contract allowed a 2% variance on good-case yield with no credit owed inside that band. Fine. Except the co-packer was billing at the high edge of that band nearly every run — reporting yield losses right up against 2% almost every time, which is statistically weird for a line that should sometimes overperform.

Do the math. At ~1,800 cases and a landed value of about $22 a case, 2% is roughly 36 cases, or around $790 per run. Across ~24 runs a year that's close to $19k sitting inside "acceptable" variance — and that's before counting the runs where they slipped past 2% and no credit was ever requested because nobody was checking.

That's the trap with variance clauses. A contracted allowance isn't a target the co-packer is supposed to hit — it's a ceiling. When every run mysteriously lands at the ceiling, the clause is being used as a pricing lever, not a tolerance.

The billing-error pattern here rhymes with what happens on the container side — the same "close enough" counting that quietly bleeds money shows up in keg fleets too, which we broke down in the lost kegs and billing errors playbook.

The daily/weekly reconciliation template

The fix isn't a better contract. It's catching discrepancies close to the run, while the co-packer's own line data is still fresh and disputable. Reconcile daily for anything that ran that day, and roll a weekly summary for AP.

Here's the core reconciliation table. Keep it to one screen. Every co-packed run gets one row.

FieldSourceExample
Run ID / dateYour scheduleCP-0417 / Apr 17
SKUYour scheduleHazy IPA 12oz 4x6
Materials sent (units)Your outbound ship20,160 cans
Expected good cases (target)Run plan1,800
Co-packer reported good casesTheir run sheet1,758
Yield variance %Calculated2.33%
Contracted allowance %Contract2.0%
Over-allowance casesCalculated~6 cases
Pallet count billedInvoice30 full
Pallet count receivedYour inbound29 full + 1 partial (48)
Pallet discrepancyCalculated12 cases short of full
Rate appliedInvoice$0.42/case
Rate expectedContract tier$0.42/case
Flag?AutoYES — yield + pallet

Two columns do the heavy lifting: yield variance vs. contracted allowance, and pallet billed vs. pallet received. That's where the money hides.

Keep the reconciliation table to one screen so reviewers can process rows quickly.

The pallet row matters more than people expect. Co-packers bill and ship by pallet, but pallet math and case math diverge constantly. A run that's 12 cases short of filling a pallet still occupies a pallet position, still gets a pallet line on the freight bill, and often gets counted as a full pallet on the pack-out. If you only reconcile at the case level, you miss it. If you only reconcile at the pallet level, you miss partials. You need both, side by side.

Setting acceptable variance rules that actually hold

A variance rule is useless if it only defines a percentage. It needs three parts:

  1. The band — e.g., ±2% good-case yield.
  2. The direction expectation — variance should distribute around zero over time, not cluster at the ceiling. This is the part almost every contract forgets.
  3. The trigger for a credit — anything past the band gets a credit request, no negotiation, tracked automatically.

The directional piece is the one that changes behavior. Add a clause, or at minimum an internal rule, that says: if reported yield loss exceeds the midpoint of the allowance band on more than X consecutive runs, it triggers a review regardless of whether any single run breached the ceiling. That kills the "always land at 1.9%" game.

Here's a workable tiering for variance response:

  1. Inside the band, distributed normally → no action, log it.
  2. Inside the band but clustering high (3+ runs above midpoint) → flag for pattern review, raise it at the monthly ops call.
  3. 1–3% past the band → automatic credit request, standard template.
  4. Over 3% past the band, or a pallet miscount over one full pallet → escalate immediately, hold the AP approval on that invoice.

Set the numbers to match your own contract. The structure is what matters: not one line in the sand, but graduated responses so small stuff gets logged and big stuff gets stopped before payment.

Credit-request templates

When you find a discrepancy, the speed and cleanliness of your request decides whether you actually get the credit. A vague "hey, this looks off" email gets slow-walked. A structured request with the run data attached gets processed, because the co-packer's own AP team can verify it quickly.

> Subject: Credit request — Run [CP-ID], SKU [name], [date] > > Run: CP-0417, Hazy IPA 12oz 4x6, packed Apr 17 > Issue: Reported good-case yield 1,758 vs. contracted minimum (2% allowance) of 1,764. Shortfall of ~6 cases past allowance. > Secondary issue: Pallet 30 billed as full; received as partial (48 cases). 12-case discrepancy. > Materials reference: 20,160 cans shipped (BOL #___), sufficient for 1,800 cases at spec. > Requested credit: 18 cases @ $0.42 pack rate = $7.56, plus freight adjustment for one partial pallet billed as full. > Supporting docs attached: inbound receiving count, your run sheet, contract variance clause §4.2.

Small dollar amounts feel not worth the email. That's exactly the psychology that lets it compound. The point of a template is that filing the request costs two minutes, so the small ones actually get filed. Eighteen cases here, twelve there, across two dozen runs — that's the $19k.

The escalation ladder

Rung 1 — Line-level log (internal). Small, distributed variances inside the band. No contact. Just recorded so the pattern is visible later.

Rung 2 — Standard credit request (AP-to-AP). A single run past the band or a pallet miscount. Template email to your co-packer's billing contact. Expect resolution in one billing cycle.

Rung 3 — Ops-level review. Same discrepancy type showing up 3+ runs in a row, or a credit request that went unanswered past 10 business days. This goes to your production manager and their plant scheduler, not AP. Frame it as a process question — "why is yield clustering here?" — not an accusation.

Rung 4 — Contract/account review with AP hold. A breach over 3% past band, a pallet miscount over one full pallet, or a pattern that survived a Rung 3 conversation. Hold payment on the disputed line (pay the undisputed remainder), and put it in front of whoever owns the co-packer relationship. This is where the contracted variance clause gets cited by section number.

The ladder works because it gives your team permission to not escalate small things while guaranteeing big things don't get quietly approved by a busy AP clerk trying to clear the batch before Friday.

The workflow, start to finish

Here's how this runs in practice on a single co-packed batch:

  1. Before the run — the run plan is locked with expected good cases, materials sent, contracted rate tier, and the variance band pulled from the current contract.
  2. Day of pack-out — co-packer's reported good cases and their pallet pack-out sheet come back. Your receiving team counts inbound pallets independently, including partials, and logs actual cases per pallet.
  3. Same-day reconciliation — the run row gets filled. Yield variance and pallet discrepancy calculate against the contract. Anything past band or over a pallet auto-flags.
  4. Within 48 hours — flagged runs generate a credit request from the template. Clean runs get logged and closed.
  5. Weekly — a summary rolls up

    total variance filed, credits received, credits outstanding, and the directional pattern per SKU.

  6. Monthly — the directional pattern report drives the ops call. Any SKU clustering at the variance ceiling gets raised.

The receiving-count step in #2 is the one breweries skip most often, and it's the one that makes everything else real. If you accept the co-packer's pack-out count as truth, you have nothing to reconcile against — you're just re-typing their numbers. An independent inbound count, even a rough pallet-and-partial tally, is the anchor for the whole system.

Operational software helps here in a pretty unglamorous way: it holds the contract terms and rate tiers next to the run data so the variance calc happens automatically instead of in a spreadsheet someone forgets to update. When a run's reported yield trips the band, the flag fires and the credit-request draft populates from the run row — so the two-minute task actually gets done instead of forgotten. The pattern-detection piece, the "this SKU always lands at the ceiling" signal, is something a human reconciling one invoice at a time will basically never catch on their own. It's the same logic as tightening any repeatable production process — the gains come from removing the manual step that keeps getting skipped, the way time-motion checklists cut changeover downtime by making the routine parts automatic.

Visual workflow: planning → pack-out → same-day reconciliation → weekly summary → monthly ops review.

Process diagram

This visual maps the key checks and escalation points.

A real scenario

A mid-size craft brewery co-packing four canned SKUs was approving invoices on a monthly AP run with a quick "does this look about right" glance. Yield variances were inside the contracted 2% band, so nothing ever got questioned.

Once they started reconciling each run within 48 hours and logging the directional pattern, two things surfaced. First, three of four SKUs were landing above the variance midpoint on nearly every run — the ceiling-clustering pattern. Second, roughly one in five runs had a pallet billed as full that had shipped as a partial.

They didn't blow up the relationship. They took the pattern to a Rung 3 ops conversation with the plant scheduler, showed the clustering data, and asked why. The co-packer tightened their reject counting and started reporting partials honestly. Over the following two quarters, filed credits and corrected yields recovered somewhere in the range of $12k–$16k, and the ongoing overbilling largely stopped because the co-packer now knew someone was counting.

The recovered money mattered. But the bigger signal was that the ceiling-clustering disappeared — which tells you it was never really yield loss.

When this is worth it — and when it isn't

This level of run-by-run reconciliation pays off when co-packing is a meaningful share of your volume — multiple runs a month, several SKUs, a contract with a variance clause you can actually cite. If you're doing two or three co-packed runs a year, a full daily template is overkill; a careful one-time reconciliation per invoice is enough.

It's also not worth the friction if your co-packer's counts already distribute normally around zero and their partials come billed as partials. Some co-packers are genuinely clean. Reconcile a quarter's worth of runs, look at the directional pattern, and if variance scatters both ways and pallets match — you've got a good partner. Log lightly and move on.

Where it absolutely earns its keep: any time variances only ever go one direction. That's not tolerance. That's a pricing lever, and the reconciliation habit is how you take it back.

Bringing it together

Co-packer invoice reconciliation isn't really about catching one bad invoice. It's about making the small, deniable discrepancies visible enough that they stop happening — because the whole game depends on nobody counting. A daily reconciliation row, a variance rule that watches direction and not just the ceiling, a two-minute credit-request template, and an escalation ladder that stops the big ones before payment. That's the entire system. It's tedious, and that's exactly why it works: almost nobody does it, which is why the money's been sitting there.

Built for Breweries Tailored to craft brewery production and sales workflows
Save Time Automate scheduling, inventory, and quality control tasks
Optimize Quality Maintain consistent brews with streamlined quality checks
Grow Sales Track and expand distribution channels effectively