This guide covers the lifecycle from order and quote to carrier invoice and client billing. For field-level controls and exceptions, continue to reconciliation best practices.
Reconciliation should not be a month-end repair task. It belongs to daily shipping operations. Teams can only evaluate carrier strategy correctly when order_id, shipment_code, charge breakdown, reversals, and exception records stay in one data chain.
This page works through six things in an executable order: what closing a shipment actually means, the four kinds of variance, the minimum field contract behind the ledger, the reason codes and targets that close each variance, an assumed split of one month of variance, and where reconciliation ends and claims or customer compensation begin.
Cost diagnosis, step 4: Reconcile the invoice. Keep the issue scope and original evidence, assign owners to open items, and continue after verification.
Assign the reconciliation owners through the 3PL shipping operating model. Use the quote-to-final-charge guide when tracing why the same shipment has different values at quotation, purchase, adjustment, and settlement.
Shipping reconciliation is not a subtraction between two totals. It joins three shipment-level records: what the team planned and purchased, what the warehouse and carrier actually executed, and what the carrier invoice and customer or client billing finally recognized. A shipment can close when the records agree; otherwise the variance enters an exception queue with a reason, owner, and due date.
| Record | Core question | Minimum fields |
|---|---|---|
| Order and label purchase | Why was this service and amount selected? | Order, shipment, quote version, carrier, service, purchase amount |
| Execution and event history | Was the parcel handed off, rerouted, relabeled, or returned? | Parcel attributes, scans, exceptions, voids, refunds, and reship links |
| Carrier and client billing | Are final charges, adjustments, and pass-through billing explainable? | Invoice row, charge type, net amount, currency, period, and client owner |
Illustrative scenario: a label is purchased and then voided, and the warehouse buys a second label for the same order. If the replacement does not retain the original shipment relationship, finance sees two charges but cannot tell which one should be refunded and which one was handed to the carrier. The failure is not the report format; the record relationship broke during relabeling.
| Field layer | Business value | Common risk |
|---|---|---|
| Order and label identifiers | Charge ownership traceability | Field mismatch breaks joins |
| Charge breakdown fields | Distinguish true cost components | Total-only view hides root cause |
| Reversal and refund fields | Explain net charge movement | Reversal cannot be traced to source shipment |
| Tracking and exception fields | Support billing dispute investigation | Ops and finance use disconnected context |
The four layers above are only categories. Whether reconciliation is possible depends on whether those fields actually exist at shipment level. The table below is the suggested minimum set, and it belongs in a build requirement rather than a reporting preference: a missing field shows up two months later as an unexplainable charge instead of on the same day as an error.
| Field | Typical source | Required | What breaks without it |
|---|---|---|---|
| Internal shipment key | Label purchase system | Yes | Only totals can be compared; the three records cannot be joined |
| Tracking number | Label purchase system | Yes | Invoice rows cannot be joined to internal records |
| Original-shipment link | Label purchase system | Required on reprint or reship | A duplicate charge cannot be traced back |
| Pricing basis version and purchase amount | Platform or contract | Yes | A basis change cannot be told apart from an error |
| Billable weight and dimension inputs | Packing and weighing step | Yes | A weight adjustment has no defence |
| Handoff and first scan timestamps | Warehouse system and tracking | Yes | A timing variance cannot be located |
| Void and credit reference | Label purchase system | Required whenever a label is voided | There is no way to confirm the credit arrived |
| Charge type | Invoice detail | Yes | A total-only view hides the root cause |
| Billing period and invoice number | Invoice detail | Yes | Period attribution blurs and the same item is claimed twice |
| Currency and exchange-rate basis | Invoice and finance system | Required for multi-currency accounts | Net amounts stop being comparable and noise enters the variance |
| Client or cost owner | Contract or platform | Yes | Pass-through billing becomes unexplainable and client questions stay open |
| Reason code and owner | Reconciliation workflow | Required on every open item | Items age in the queue with nobody responsible for recovery |
Closing a shipment is a decision with four parts. The net amount is confirmed, the action that produced it is identified, the evidence is attached, and the root cause is coded. Miss any one of the four and the item stays in the aging queue. That is why matching totals are not proof of a clean ledger: offsets hide per-shipment errors.
| Action | When it is the right choice | Who approves | Effect on the provider invoice | Effect on the client bill | Evidence to keep |
|---|---|---|---|---|---|
| Write in | The invoice line is real and the internal ledger never recorded it | Finance | No change | May change client attribution | Original invoice line and the ledger correction |
| Void or credit | The label was never used, or one shipment was purchased twice | Operations initiates, finance confirms receipt | Reduces the net amount | Usually not passed through | Void timestamp, credit confirmation, original-shipment link |
| File a dispute | The amount contradicts the agreed basis and the provider can verify it | Finance files, operations supplies evidence | May reduce the net amount | Attribution follows the outcome | Pricing basis in effect, weight and dimension inputs, tracking |
| Write off | The amount sits under an approved threshold and the trail is gone | Finance within an approved threshold | No change | Pass-through follows the same threshold | Approval record and reason code |
| Client adjustment | Attribution or basis was wrong on the client side | Client owner with finance | No change | Creates a debit or credit | Contract clause and the basis for the adjustment |
Three situations should not be closed even when a number is available. An item that cannot be traced to a shipment, an item claimed in two queues at once, and an item whose reason code is still unknown. All three look finished while nothing was actually resolved.
Classifying first avoids the most expensive mistake in reconciliation: treating a record problem as a pricing problem, then filing a dispute the internal data cannot support.
| Category | How to recognize it | Common root cause | First action | Evidence needed to close |
|---|---|---|---|---|
| Amount variance | One shipment appears with two different amounts | A different basis in effect, different weight inputs, or an extra charge with no support | Pull the basis in effect and the weight and dimension inputs for that shipment | Basis in effect, label inputs, measurement record |
| Status variance | The ledger and the invoice disagree about what happened to the shipment | A void that never produced a credit, a reprinted label, a reshipment, or a missing scan | Reconstruct the history from purchase to the final event | Void timestamp, credit confirmation, original-shipment link |
| Period variance | The amount is right and it lands in a different billing period | Cut-off timing, a late adjustment, or a reissued invoice | Match on the shipment date as well as the invoice date | A written period definition and the item's first appearance on an invoice |
| Ownership variance | The amount is correct but belongs to another client, facility, or channel | Shared accounts, platform routing, manual reassignment | Apply the attribution rule in the contract, not the screen that created the label | Contract clause and the routing record |
A variance only becomes manageable once it carries a code, an owner, and a target. The targets below are recommended thresholds for planning purposes, not contractual service levels.
| Reason code | Meaning | Owner | Target (recommended threshold) | Closure evidence |
|---|---|---|---|---|
| duplicate-purchase | A timeout retry or a repeat click purchased the same shipment twice | Operations | Next business day | Both purchase records and the credit confirmation |
| void-pending | The label was voided but the credit has not appeared. Unused Click-N-Ship labels are eligible for a refund up to 60 days after the print date (USPS refund information); other channels set their own windows and conditions. | Operations and finance | Within one billing period | Void timestamp and credit confirmation |
| weight-adjustment | Weight or dimensions were re-measured | Operations and finance | Within one billing period | Measurement record or corrected inputs |
| address-correction | The address changed after the label was created | Support and operations | Next business day | Change request and the new label |
| unsupported-accessorial | An extra charge appears with no supporting record | Finance | Before the provider's window closes | Provider confirmation or a filed adjustment request |
| missing-invoice-row | An internal record exists and the invoice has no matching row | Finance | Within one billing period | Provider statement and the internal purchase record |
| ownership-mismatch | The charge belongs to another client, facility, or channel | Client owner | Within one billing period | Contract clause and the routing record |
| Stage | Pass condition | Failure path |
|---|---|---|
| 1. Capture | Every purchase, void, refund, and reship has stable identifiers | Quarantine missing or duplicate records |
| 2. Normalize | Charges, statuses, currency, and timestamps use shared definitions | Map to a review reason code |
| 3. Match | Operational, carrier, and client records join at shipment level | Enter unmatched or amount-variance queue |
| 4. Resolve | Owner completes evidence, reversal, dispute, or client adjustment | Escalate and record the blocking party |
| 5. Close and learn | Net cost is approved and root cause feeds packaging, routing, or workflow rules | Retain in aging queue; never silently close |
Assume a 3PL closes one billing period with a net variance equal to 0.8 percent of monthly spend, spread across four causes. Every number in this section is an assumed input used to show how the work is organised. None of it is a customer result, a quoted amount, or a savings promise.
| Cause (assumed) | Share of monthly spend | Recovery action | Assumed recovery window | Reflected in the same period |
|---|---|---|---|---|
| Weight and dimension adjustment | 0.30% | File an adjustment with the measurement record | 10 to 20 days | No, usually a later credit |
| Voided label without a credit | 0.25% | Check the void window and confirm the credit | 5 to 10 days | Partly |
| Re-shipment double charge | 0.15% | Block duplicate purchases, then request an adjustment | 10 to 20 days | No |
| Missing invoice row | 0.10% | Write in and confirm client attribution | 1 to 3 days | Yes |
The split produces two conclusions. First, the largest cause is usually not the only one worth fixing: the smaller causes decide how much work the queue generates each month and whether the aging bucket keeps growing. Second, the amount requested in a period is not the amount received in that period, so a monthly recovery figure on its own overstates the result. Read it next to the aging queue.
Reconciliation usually fails because everything is pushed to month end rather than because a process is missing. Distributing the work across four frequencies gives an exception a chance to be handled before it becomes a dispute.
| Frequency | What happens | Output | Owner | Escalation trigger |
|---|---|---|---|---|
| On every purchase (automated) | Capture and quarantine: missing keys, duplicate requests, voids without a receipt | Quarantine list | Systems and engineering | The missing-key rate crosses the agreed threshold |
| Daily | Event alignment: whether purchase, void, credit, and reship appear in pairs | Working list | Operations | An unexplained void or credit sits unattended |
| Weekly | Matching and triage: variance and aging grouped by reason code | Triage report | Finance and operations | One reason code rises two weeks in a row |
| Each billing period | Invoice review, adjustment requests, client adjustments, closure | Closure list and open aging | Finance | An item cannot be traced to a shipment |
| Quarterly | Root-cause writeback: packaging, routing, thresholds, service choice, and basis review | Rule change record | Operations and finance | The same problem repeats across clients or facilities |
For a finer-grained control cadence and review method, continue to shipping reconciliation best practices. For the field design itself, see the order, shipment, and label data model.
One shipment can appear in three queues at once: a reconciliation variance, a claim against the provider for a loss or damage, and a customer refund or compensation. Each has its own owner and its own clock. Before opening any of them, assign one primary queue for that shipment. Without a primary owner the same recovery gets counted twice, or the same loss gets paid out twice.
| Queue | What triggers it | Owner | Output | Handoff |
|---|---|---|---|---|
| Reconciliation variance | The internal ledger and the invoice disagree | Finance | Write-in, reversal, dispute, or client adjustment | Operations supplies shipment-level evidence |
| Provider claim | The promised service was not performed, or the parcel was lost or damaged | Operations | Settlement, denial, or an open claim | The settlement amount is written back to the ledger |
| Customer compensation | A customer disputes the outcome or the promise | Support | A refund or compensation decision | The cost is booked to the client owner and a reason code |
One rule of thumb separates them: a variance answers whether the charge belongs in the ledger at all, a claim answers whether the service was performed, and customer compensation answers what the customer lost because of it. Each can supply evidence to the others, but they cannot share one closure standard.
Bring the diagnosis into the ledger by linking order, parcel, label, tracking, and invoice line. Retain separate records for multi-parcel orders, voided/replaced labels, returns/re-sends, and post-period adjustments. A tracking number or a similar amount can help locate a record but does not by itself prove that an invoice line should be closed.
| Reconciliation item | Evidence before closure | Ownership |
|---|---|---|
| Identity and amounts | Quotes, purchased charges, adjustments, reversals, and net cost belong to an identified segment. | Engineering owns identity/versioning; finance confirms the amounts. |
| Valid charges and input errors | Effective service rules and measurement records explain the charge change. | Operations corrects inputs; finance verifies allocation. |
| Substantiated disputes | Error reason, evidence pack, submission, case ID, and deadline are recorded. | The account/platform owner submits; finance follows the actual credit. |
| Client charges and credits | Terms, notifications/approvals, client invoices, and received credits align. | Finance and the client owner confirm; adjustments are not automatically passed through. |
Keep unexplained lines pending. A submitted dispute is not a received credit, and an approved refund is not yet recovered cash. Allocate late charges and reversals to the original segment, preserving the prior closure version and reason for reopening. Do not subtract an expected refund from current cost as if it had already arrived.
For evidenced weight or dimension issues, use the weight adjustment dispute guide. Return valid but expensive charges to cost triage to investigate execution or selection. Once the evidence closes, proceed to improvement verification and assess cost and service together.
Not on submission alone. Track the case decision, credit memo, and actual receipt separately, and correct client billing under the agreed policy. Keep incomplete parts open.
Align billing fields and workflows first, then scale carrier strategy with lower operational and financial friction.
Carry the evidence, open items, and owners to the next step. For valid but high charges, investigate execution or selection; do not default to a dispute without evidence of a specific error.
For reconciled invoices without a dispute, go directly to improvement verification.
When billing cannot resolve to the source system, client, or label, use the system-onboarding path to review ownership/data and failure-path acceptance for duplicates, timeouts, missing events, and amount closure. A successful response does not replace finance’s confirmation.
Each provider sets its own adjustment window and evidence requirements and updates its terms. Before relying on any deadline, confirm it against the current terms on your own account.
