3PL Carrier Invoice Allocation to Client Billing

3PL carrier invoice allocation is the upstream workflow that turns incoming carrier, warehouse, and supplier invoices into client-billable line items before they enter a 3PL billing engine. Each line is mapped to a client account using a shipment, order, or reference key, flagged as pass-through or markup, and routed for exception review. The output is auditable source data ready for client billing and margin analysis.

Three roles sit on the workflow. The 3PL is the recipient of the bills: parcel and LTL carrier invoices, warehouse and fulfillment supplier statements, third-party packaging invoices, labor reports, fuel and accessorial supplements. The carrier or supplier is the upstream source, whose bill needs decomposing into client-allocable lines. The client is the downstream rebill target, whose invoice the 3PL eventually produces from those allocated lines. Everything in this article assumes that orientation.

Allocation sits before whatever billing engine the 3PL already runs. Extensiv, ShipHero, Logiwa, Da Vinci, and custom internal systems each have their own opinions about how billable lines should look once they arrive, but none of them solves the problem of getting clean, client-mapped, markup-flagged lines into the system in the first place. That upstream layer is what the schema and workflow below describe. The tool we build, Invoice Data Extraction, sits at the same upstream point: it can extract structured line-item data from carrier and supplier invoice PDFs into Excel, CSV, or JSON that any billing engine can ingest. It is not a billing engine, an allocation engine, or a 3PL platform; it is the data layer.

This is the side of the transaction worth being explicit about, because search results for these phrases drift across roles. If you are a merchant auditing a single bill from your 3PL, you want the buyer-side 3PL invoice audit workflow — different reader, different document, different question. If you are managing fulfillment across several providers and need to bring those bills into a single view, the workflow for consolidating fulfillment invoices from multiple 3PL providers is the right starting point. Neither is this article. This article is for the 3PL operator on the other end of those workflows — the team that receives the carrier, warehouse, and supplier bills and has to turn them into clean client billing.

What follows is the data layer for that work: the field schema each incoming line needs to carry, the intake-to-billing-handoff workflow that produces it, the line-level pass-through-vs-markup logic that decides what each line becomes on a client invoice, the document-format breadth that goes beyond parcel, the exception taxonomy that keeps the review queue from becoming a dumping ground, and the month-end margin loop that the same data feeds once billing completes.

---

The Extraction Field Schema for Client Allocation

Before any line can be billed to a client, it needs to land in the same shape every time. The schema below is the working spec: twenty fields, three columns of commentary, intended to be lifted straight into a spreadsheet, an extraction prompt, or a billing-engine import template. It applies whether the source document is a UPS summary, a fulfillment partner's monthly statement, or a packaging supplier's invoice — the fields stay the same, the source-document specifics change.

Field	What it carries	Why it matters for allocation
Supplier or carrier	The entity that issued the bill	Drives rate-card lookup and the per-supplier reconciliation path
Invoice number	The supplier's invoice identifier	Anchor for duplicate detection and supplier-side credit-back requests
Invoice date	The date the invoice was issued	Used for AP aging and for separating invoice date from service date
Service period start	First day of the window the line covers	Drives client billing-window assignment, not the invoice date
Service period end	Last day of the window the line covers	Holds late-arriving supplements in their correct billing window
Client / account key	The identifier that maps the line to one of the 3PL's customers	The most consequential field in the schema; allocation is impossible without it
Shipment / order / reference number	The granular event the line attaches to	Enables order-level cost reporting and audit traceability
Warehouse or fulfillment location	The site where the work was performed	Fallback mapping signal when the client key is missing or ambiguous
Service code	The carrier's or warehouse's internal code for the work delivered	Maps to rate-card line items and to the client contract's billable scope
Line description	Human-readable text from the source document	Reviewer context; useful when the service code is unfamiliar
Quantity	Units billed on the line	Drives per-unit rate validation and pro-rata allocation
Rate	Per-unit cost on the line	Compared against the contracted rate card to surface rate mismatches
Line total	Total cost for the line as billed	Reconciles to invoice total and feeds margin reporting
Tax	Sales tax, VAT, or GST on the line	Kept separate from cost so markup bases are unambiguous
Fuel surcharge	Carrier or supplier fuel charge	Its own pass-through-or-markup decision per client contract
Accessorial charge	Carrier or supplier add-on charge (liftgate, residential, redelivery, etc.)	Frequent exception source; requires per-line authorisation check
Handling charge	3PL-specific handling fee tied to the line	Almost always carries a flat or percentage markup
Pass-through-vs-markup flag	Line-level decision: pass-through, flat markup, percentage markup, or absorbed	Determines what amount appears on the client invoice
Billable status	billable, absorbed, disputed, or pending	Independent of the markup flag; controls whether the line is released to billing
Source document filename or ID	Pointer back to the underlying PDF and page	Audit trail; every client query about a charge resolves here
Exception reason	Empty unless flagged	Carries the taxonomy category back to the line

A few fields earn their own commentary.

Client / account key is the field that decides whether allocation runs cleanly or grinds. On a parcel carrier summary it usually lives inside the shipment reference, populated by whatever rate-shopping or label-buy step the 3PL ran. On a warehouse statement it might be present at line level or only inferable from origin warehouse and service period. On a labor report or a packaging supplier invoice it is rarely on the document at all and has to be reconstructed downstream from pick counts, shipped volume, or inventory consumption. Every allocation project that goes badly went badly here first.

Pass-through-vs-markup flag and billable status are two separate fields, not one. A line can be markup-percentage and pending; pass-through and disputed; flat-markup and absorbed. The markup decision answers what amount the client should see; the billable status answers whether the line is ready to be released to billing this period. Collapsing them into a single field loses information the team needs the moment any line moves through resolution.

Source document filename or ID and exception reason are operational fields, not invoice fields. They exist so a line can be traced back to its PDF without leaving the schema, and so an exception's category travels with the line through review and billing. A schema that omits them treats the spreadsheet as a snapshot; including them treats it as a working artifact.

The fee fields — fuel, accessorial, handling — sit as separate columns rather than collapsing into one "other charges" bucket on purpose. Each is its own pass-through-or-markup decision and often its own client authorisation question. Compressing them into a single field hides exactly the spectrum of fees and surcharges hidden in 3PL invoices that need their own per-line treatment.

The schema is implementable as a prompt-driven extraction template — Invoice Data Extraction takes a natural language prompt listing fields like the ones above, processes mixed-format PDFs in batch, and returns structured Excel, CSV, or JSON where each row carries a reference back to the source file and page. That gives the operational fields a direct home: the source-document pointer is populated automatically, leaving the team to fill in client key, pass-through flag, and billable status during the allocation pass.

---

The Intake-to-Billing-Handoff Workflow

The schema is a contract; the workflow is the sequence that fills it. Six numbered stages, each with a defined input, a defined action, and a defined output that becomes the next stage's input. The discipline is keeping the stages distinct: when intake quietly becomes extraction, or when mapping bleeds into exception review, the workflow stops being repeatable.

1. Intake of heterogeneous source documents. Input: whatever arrives. Carrier PDFs in email attachments, warehouse statements pulled from supplier portals, fulfillment supplier invoices posted to a shared drive, labor reports forwarded from a staffing agency, packaging invoices that come monthly, fuel and accessorial supplements that arrive a week behind the main bill. Action: land every document into a single intake queue with a consistent filename convention (supplier-date-invoice-id is usually enough) and a consistent storage location. Output: a queue of source PDFs ready to be processed as a batch rather than ad hoc. The point of doing this as its own stage is that batch processing — schema-wise and operationally — only works if the inputs are pooled. A one-off "I'll just process this one when it comes in" pattern is what produces six different ad hoc allocation processes by month six.

2. Extraction into the schema. Input: the intake queue. Action: parse each document into the field schema from the previous section, producing one row per line, not one row per invoice. Output: a structured dataset — Excel, CSV, or JSON — where each row carries the supplier, the service period, the rate, the line total, the source document reference, and an empty client key, markup flag, billable status, and exception reason ready to be populated downstream. Line-item granularity is what makes the rest of the workflow possible; a row per invoice cannot be allocated to a client.

3. Client / account mapping using the reference key. Input: the extracted line-item dataset. Action: match each line to a client account using the shipment, order, or reference number. When the key is present and clean, this is a direct lookup against the 3PL's client master. When the key resolves to more than one candidate client — common with shared rate-shopping accounts or reused reference patterns — the line goes to the ambiguous-reference exception path. When the key is missing entirely (typical for warehouse statements and labor reports), the fallback is warehouse plus service period plus, where necessary, manual assignment by an operations reviewer who knows which client was active in that window. Output: a dataset where every line is either mapped to a client or routed to exception review with the reason recorded. This stage is where most allocation time goes when the upstream data is noisy.

4. Exception review against the taxonomy. Input: lines that failed mapping, lines whose rate disagrees with the contracted rate card, lines outside the active service period, duplicates, lines without source authorisation, and any line the schema's exception-reason field has been populated against. Action: work the review queue using the taxonomy detailed in a later section, resolving each line according to its category's defined path. Output: exceptions either resolved (line returns to the billing-ready dataset with markup flag and billable status set) or held (line carries a disputed or pending status into the next billing cycle). The discipline is that exceptions are made visible before billing handoff, not discovered by the client after the invoice goes out.

5. Handoff to the 3PL billing engine. Input: the cleaned, allocated, exception-cleared dataset. Action: deliver it to whatever billing engine the 3PL runs, in the format that engine expects to ingest — usually a structured CSV, Excel, or JSON import. Output: client invoices generated by the billing engine. The workflow is billing-engine-neutral by design. Extensiv, ShipHero, Logiwa, Da Vinci, and custom internal billing systems all have their own quirks around how billable lines should be formatted on import, but none of that changes the upstream work. What changes is the file shape at handoff; the schema and the allocation logic stay the same. The workflow ends here; what the billing engine does with the lines afterward is the engine's job, not the allocation workflow's.

6. Month-end margin and profitability loop. Input: the same allocated cost lines, now matched against the billed revenue they produced. Action: feed cost-per-client, cost-per-order, and contribution-margin reporting. Output: the answer to which clients and which order patterns are actually profitable. Sequence-wise this closes the loop and is treated in detail in the final section.

This sequence is not novel at enterprise scale. Microsoft's Dynamics 365 freight reconciliation documentation describes the same matching pattern inside a TMS: freight reconciliation is the process by which system-generated freight bills containing estimated freight costs are matched to the actual invoices received from carriers, with any differences treated as variances that must be reconciled. The recognised industry pattern exists. What is missing for most small and mid-sized 3PLs is the TMS that runs it automatically. They are running the same workflow manually against carrier and warehouse PDFs, which is exactly the population this article is written for.

---

Pass-Through vs Markup as a Line-Level Decision

The mistake worth naming up front: pass-through versus markup is a per-line decision, not a contract-level switch. A single client contract routinely carries pass-through parcel postage, a flat markup on handling, a percentage markup on warehouse storage, and absorbed pick fees on goodwill credits — sometimes on the same shipment. Treating the markup decision as one global setting per client is how billing engines and finance teams produce client invoices that look defensible at the totals line but unwind the moment a client questions an individual charge.

The line-level decision resolves to one of four markup states.

Pure pass-through. The line is billed to the client at the supplier's actual cost, no margin added. Common for parcel postage where the contract specifies pass-through, for carrier fuel surcharges treated as a recoverable, and for specific accessorials the client has explicitly authorised. The data model needs to carry the supplier's original cost untouched on the line — any rounding or fee absorption applied at billing time loses the audit trail back to the supplier invoice. If the client asks why their pass-through cost differs from the carrier's published rate, the answer needs to live on the line, not in someone's head.

Flat markup. The line is billed at the supplier's cost plus a fixed amount in the contract currency. Common for handling lines where the 3PL adds a per-pick or per-shipment fee on top of the underlying labor or carrier cost. The markup amount is part of the rate card and travels with the line so the billed amount reconciles cleanly back to the supplier's invoice plus the flat fee, with nothing inferred.

Percentage markup on a base. The line is billed at supplier cost multiplied by a contracted percentage — for example, carrier cost plus fifteen percent. The base needs to be unambiguous, because clients will ask. Is it cost before tax or after? Cost including fuel surcharge, or excluding? Cost including accessorials, or excluding them so they pass through at a different percentage? The contract specifies the base; the rate card documents it; the line carries it. Without the base recorded on the line, two reviewers will compute the same percentage markup differently a month later and neither will know who is right.

Absorbed (non-billable). The cost was incurred by the 3PL but is not billed back to the client. Service-recovery credits, errors the 3PL caused, charges falling outside the client contract's billable scope, goodwill writeoffs on edge-case accessorials — these are all absorbed. The cost still belongs in margin reporting, even though it does not belong on a client invoice. An absorbed line that disappears from the data after billing is an absorbed line that does not show up in next month's contribution-margin report, which is the report whose entire purpose is making absorbed cost visible.

Billable status is the fifth state — and it is a separate field, not a fifth markup type. Billable, absorbed, disputed, pending. A line can carry markup-percentage and pending: the markup decision is settled at fifteen percent, the line is just being held back from billing this period pending resolution of a rate-card question. A line can be pass-through and disputed: the markup is zero, but a duplicate-charge investigation is open. A line can be flat-markup and absorbed: the markup methodology is documented even though the 3PL has decided not to bill the line in this case. Collapsing the markup flag and the billable status into a single field deletes information the team uses in every review cycle.

The schema implication is straightforward. The markup flag carries the type: pass-through, flat, percentage, or absorbed. Where the type has a value attached — the flat amount or the percentage — that value sits in its own attribute alongside the flag. The base of a percentage markup is a third attribute, never inferred. Without these explicit on the line, the billing engine has to re-derive the markup decision from rate-card heuristics at invoice generation time, and it will get it wrong in the same way every cycle.

Pass-through lines also need their own reconciliation discipline. When the contract specifies pass-through but the actual carrier cost on the invoice differs from what was originally quoted or accrued, that variance is its own exception (covered in the next section). The reconciliation logic is identical to freight reconciliation at enterprise scale — actual minus estimated, variance routed for review — only the execution surface changes. Instead of running inside a TMS, the same matching is happening manually against PDFs. The pattern is the same; the tooling is not.

---

The Full Document Mix Beyond Parcel Carrier PDFs

Most published guidance on 3PL carrier invoice allocation quietly assumes parcel scope. Tracking-number-keyed, billing-engine-ingestable, designed around the UPS or FedEx EDI feed that ShipHero or Extensiv already understands. That covers maybe half of what an actual 3PL allocation queue looks like. The other half is where the manual hours accumulate.

Parcel carrier invoices. High-volume, tracking-number-keyed, often delivered as multi-thousand-line summary files or weekly EDI feeds. The reference key — the tracking number — is usually present and clean, which is why parcel is the part the SERP gets right. The complication is at the rate-card level: zone, service type, dimensional weight, residential surcharge, delivery area surcharge, peak-season surcharge, and Saturday delivery each contribute to the line's rate, and rate validation has to walk all of them to know whether the carrier billed correctly. Pass-through versus markup is usually decided per-service-type in the client contract rather than per-line; the line's job is to carry enough rate-detail context that the markup decision can be applied without reinterpretation.

LTL and TL freight invoices. Lower-volume per shipment but information-dense, usually multi-page, keyed by BOL or pro number. Accessorials sit on their own lines (liftgate, residential delivery, limited-access, redelivery) and weight or class adjustments arrive after the original quote was issued, often weeks later as a separate corrective invoice. Variances against the originally-estimated freight bill are the rule, not the exception. The depth of automating carrier freight invoice data extraction on these documents is what keeps the LTL piece tractable; without it the team is back to keying multi-page PDFs by hand. Freight brokers running the adjacent workflow face the same matching problem from the other direction — matching carrier invoices to rate confirmations and BOL/POD evidence before pre-pay release covers that pre-pay audit pattern in detail.

Warehouse and fulfillment supplier statements. Often a single monthly statement covering thousands of pick, pack, storage, and inbound receipt events. Some statements break the activity down to shipment level; many do not, and the 3PL has to back-calculate per-client allocation from totals and known storage occupancy or pick counts. The client/account key is rarely on the document itself — it has to be reconstructed from internal records of which client's inventory was active in which location over the service period. Warehouse statements are the format that breaks ad hoc workflows the fastest, because the back-calculation step doesn't fit into a parcel-shaped pipeline.

Labor reports from staffing agencies. Hours-based rather than event-based, usually per-warehouse rather than per-client. Total labor hours for the period get split across clients by shipped volume, picks, or a contracted ratio that lives in the client contract. The labor bill itself almost never carries a client reference, so allocation is entirely downstream — the labor line in the schema records the supplier and the total cost, the markup flag and the client key are populated from internal allocation rules during the mapping stage.

Packaging supplier invoices. Often per-purchase-order, with the packaging consumed across multiple clients over the weeks after the order arrives. Allocation flows through inventory consumption records rather than from the supplier invoice directly: the invoice records the cost of buying the cartons, the inventory system records which client's outbound shipments consumed them, and the allocation step ties the two together. The supplier invoice is the cost source, but the per-client distribution comes from a different system.

Fuel and accessorial supplements. Arrive separately from the underlying carrier bill, sometimes days late, sometimes a single monthly true-up that consolidates several weeks of activity. The schema's service-period field is what holds these in their correct billing window — without it, late-arriving fuel supplements either inflate the wrong client's invoice or fall off the allocation altogether. Pass-through reconciliation against these supplements is usually where the most "why is this charge different from last month" client queries originate.

Six categories, one workflow. The schema doesn't change between them; the extraction work shifts, the mapping logic shifts, and the proportion of lines routed to exception review shifts, but the destination dataset is the same. The discipline is keeping it that way — running one allocation process across all six rather than letting parcel be the well-tooled exception and treating everything else as a side workflow.

Document-format breadth is also where most allocation projects underestimate scope at planning time. Parcel is solved by every billing engine in the SERP, so it looks like the problem is solved. The warehouse-statement back-calculation, the labor-ratio allocation, the packaging-consumption tie-out, and the late-arriving accessorial supplement are where the actual manual hours live, and where the schema and workflow earn their keep. An extraction tool that handles mixed-format batches up to 6,000 documents per job, single PDFs up to 5,000 pages, and filters out cover sheets and remittance advice automatically — Invoice Data Extraction's batch handling does this — is the difference between running this as one workflow and running it as six.

---

An Exception Taxonomy for Allocation Review

The review queue exists because the workflow's stage four routes every line that cannot pass cleanly through mapping or rate validation. What the SERP calls "discrepancy alerts" is, in practice, nine specific categories. Naming them turns the queue from a dumping ground into a defensible classification — each exception has a typical trigger and a typical resolution path, and the team produces consistent decisions across reviewers instead of per-reviewer judgment calls.

Missing client / account key. The line has no shipment, order, or reference number that maps to a client. Resolution: look the line up by warehouse and service period; if that still doesn't narrow it, route to operations for manual assignment using internal knowledge of which client was active in that window. Common on warehouse statements and labor reports where the source document never carried a client reference in the first place.

Ambiguous reference. The reference key resolves to more than one candidate client. Resolution: inspect adjacent fields — origin, destination, service code, dimensional details — and narrow to the right account. Escalate when the reference is structurally duplicated across clients (shared rate-shopping accounts, reused PO numbering patterns), which is a sign the upstream reference scheme needs fixing at source.

Rate mismatch versus rate card. The supplier's rate disagrees with the contracted rate. Resolution: confirm rate card version and effective date — the most frequent cause of a rate mismatch is an out-of-date rate card on the 3PL's side, not a billing error on the supplier's. Where the supplier's rate is genuinely incorrect, raise a credit-back request. Where the contract has moved and the rate card hasn't, update internally.

Duplicate charge. The same line appears more than once across invoices or within an invoice. Resolution: confirm against the source document — a duplicate within a single invoice usually means a supplier-side mistake; a duplicate across invoices may be a corrected invoice replacing a draft, in which case one of the two needs to be suppressed before billing. Raise a credit-back if the supplier has genuinely double-billed.

Charge outside service period. The line's date sits outside the client's active billing window. Resolution: hold for the prior or next billing period, or route to the client-onboarding or offboarding workflow when the date falls into a contract-start or contract-end edge case. Particularly common with late-arriving fuel and accessorial supplements.

Accessorial without source authorization. An accessorial appears on the supplier bill without a corresponding client authorisation. Resolution: confirm the underlying event — failed delivery, redelivery, address correction, residential surcharge — and check whether the client contract authorises that accessorial type for pass-through. If yes, the line clears. If no, the line is either absorbed or escalated to a billable dispute conversation with the client.

Charge type not in client contract. The line type is not enumerated in the client's billable scope at all. Resolution: absorb the cost this period, or open a contract-amendment conversation with the client to add the charge type to billable scope going forward. The taxonomy keeps these visible so they don't quietly become an unbillable category that erodes margin month after month.

Currency or unit mismatch. The line's currency or unit of measure disagrees with what the rate card or client contract specifies. Resolution: apply the documented conversion (the contract should specify the source of FX rates and the rounding convention) and flag for FX review at month-end. Common at month boundaries when FX rates have moved meaningfully against the rate at which the contract was struck.

Supplier billing error suspected. The line is structurally wrong — impossible weight, negative quantity, service code that does not exist on the rate card, line total that doesn't match quantity times rate. Resolution: raise back to the supplier directly. Do not pass through; structural errors at the supplier level become billing errors at the client level if they're not caught here.

A bounded taxonomy works because every flagged line has a category, every category has a resolution path, and the exception-reason field on the schema carries the category back to the line itself. A reviewer who picks up a held line three weeks later can see why it was held without reconstructing the decision from memory.

Worth saying explicitly: not every flagged line means a real problem. Rate mismatches against an out-of-date rate card, currency mismatches at month boundaries, accessorial flags against contracts that haven't been updated to reflect last quarter's amendment — these are routine and benign. The point of the taxonomy isn't to imply that every exception is a supplier error or a client dispute. It's to make the cause visible quickly enough that the resolution scales with volume.

---

Closing the Loop with Month-End Margin Review

The same line-level cost data that supported allocation, exception review, and billing handoff is what supports margin reporting once the billing run completes. This isn't a new workflow — it's the same dataset queried for a different question. Allocation answers what to bill each client; margin review answers which clients and which order patterns are actually worth keeping.

Three reports fall directly out of the allocated dataset.

Cost-per-client. Total allocated supplier cost per client over the period, split by cost category — parcel, LTL, warehouse, labor, packaging, accessorial. The schema's client / account key plus the per-category cost fields are what make this report buildable without manual reassembly at month-end. When the upstream allocation is messy, cost-per-client is the report that quietly turns into "best guess based on what mapped cleanly," and the leadership conversations off the back of it follow.

Cost-per-order. Allocated cost per shipment or order, using the reference-key field that the allocation workflow populated during stage three. Useful where the 3PL needs to answer profitability at the order level — typically for clients with thin margins, variable shipping mixes, or contracts where order economics shift meaningfully across product lines. Cost-per-order is the report that surfaces individual loss-making order patterns the cost-per-client total averages away.

Contribution margin per client. Billed revenue minus allocated cost, with the markup-flag field on each line doing the reconciliation between the billed amount and the underlying supplier cost. Pass-through lines contribute zero margin by definition — the billed amount equals the cost, so neither helps nor hurts the report. Markup lines contribute the flat amount or the percentage applied to the base. Absorbed lines contribute negative margin: cost without revenue, visible as such in the report instead of disappearing into an unallocated bucket. That visibility is the entire point of carrying the absorbed status on the line rather than dropping absorbed lines after billing.

The upstream work is what makes the margin reporting defensible. Without the line-level pass-through-vs-markup flag, the report has to guess at the markup methodology from totals. Without the billable status, absorbed lines vanish and the cost-per-client number is silently too low. Without the source-document reference, no line is traceable back to a PDF when the controller asks where a particular cost came from. With them, the margin report is the same dataset the client invoice was built from, queried differently — and a client query about a charge resolves the same way a margin question about a cost does, by walking the schema back to the source document.

Billing-engine neutrality holds at the close too. The workflow described in this article hands clean, allocated data into whatever billing engine the 3PL runs, and the same data feeds back into reporting once billing completes. Extensiv, ShipHero, Logiwa, Da Vinci, and custom systems each handle the billing step differently; none of that changes what the upstream data layer looks like or what reports it supports. The article isn't an argument for a billing engine. It's an argument for the data layer underneath whichever billing engine the 3PL has already chosen — the layer that turns six categories of incoming supplier PDFs into clean, client-allocated, markup-flagged lines that are useful to billing today and useful to margin reporting next week.