Your warehouse report says most demand shipped, but customer service has a list of incomplete orders. Both reports can be correct. Fill rate measures fulfilled demand as a percentage of eligible demand, and the answer changes when you count units, complete lines, or complete orders. Keep the unit of measurement in the report title so readers can tell which question the number answers.
Use unit fill rate to measure the quantity supplied, line fill rate to identify how many requested item lines were completed, and order fill rate to measure complete orders. Calculate all three from the same order population and cutoff when investigating a disagreement. Keep your existing reporting tool if it can preserve those definitions and show the underlying shipment records; a different dashboard alone will not settle the calculation.
Choose what counts as filled before calculating the rate
Shopify’s fill-rate explanation distinguishes complete orders from fulfilled order lines. A line is one item-and-quantity request within an order. For the worked example below, a complete line means its entire requested quantity shipped by the chosen cutoff, and a complete order means every eligible line met that rule. These are explicit reporting definitions, not a claim that every software product uses the same calculation.
Unit fill rate equals eligible units shipped divided by eligible units ordered, multiplied by one hundred. Line fill rate equals complete eligible lines divided by all eligible lines, multiplied by one hundred. Order fill rate equals complete eligible orders divided by all eligible orders, multiplied by one hundred. A partially shipped line contributes its shipped quantity to the unit measure but does not count as a complete line or make its order complete.
Write down whether the measure concerns first shipment, a promised shipping deadline, or eventual fulfillment. These choices produce different results for a backorder filled next week. This example measures shipments recorded by a fixed review cutoff. It does not measure delivery arrival or customer acceptance. If the question includes arriving on the promised date, use a separately defined on-time, in-full measure with the required delivery evidence.
Calculate three rates from the same order lines
Use this hypothetical sample to check your spreadsheet or reporting logic. There are three orders and five lines. All quantities are pieces, all orders belong to the same review period, and the shipped quantity is frozen at the review cutoff. There are no cancellations, substitutions, returns, or duplicate shipment records. The sample is an arithmetic fixture, not a benchmark or a measured customer outcome.
| Order and line | Pieces ordered | Pieces shipped at cutoff | Complete line? |
|---|---|---|---|
| A / item 1 | 10 | 10 | Yes |
| A / item 2 | 10 | 5 | No |
| B / item 3 | 20 | 20 | Yes |
| C / item 4 | 10 | 10 | Yes |
| C / item 5 | 50 | 40 | No |
The sample contains one hundred ordered pieces and eighty-five shipped pieces, so unit fill rate is 85%. Three of the five lines are complete, so line fill rate is 60%. Only order B is complete, so order fill rate is one divided by three, or about 33.3%. The difference follows from the chosen denominator. No additional warehouse event is needed to explain it.
Suppose the remaining fifteen pieces ship the following morning. An eventual-fulfillment report can then show all three measures at 100%, but the frozen cutoff report must retain its original results. Preserve both snapshots if both questions matter. Replacing yesterday’s status with today’s completed status removes evidence of the service shortfall that customer service was trying to explain.
Keep shipment events separate from order quantities
Start with one row per order line containing the source order identifier, line identifier, item, requested quantity, unit, and applicable deadline. Keep shipments in a separate event table with their own identifiers and timestamps. Sum eligible shipment quantities by order line before joining them to the order population. Joining several shipment rows to one line and then summing its requested quantity repeats demand and understates performance.
Oracle’s Warehouse Management 25D report documentation separates allocated, packed, shipped, and canceled quantities and provides order and item-level views. Those states should remain distinct in your extraction too. Allocation reserves stock; it does not establish that the goods shipped. Record which event your numerator uses rather than accepting a field called fulfilled without inspecting its meaning.
Normalize pack sizes before combining quantities. If an order requests cases and the shipment export records pieces, retain the applicable conversion alongside the original values. Exclude or flag an unresolved conversion instead of assuming a standard pack. Cap counted shipment quantity at the eligible demand for each line when calculating this service measure, and investigate over-shipments separately so extra units on one line cannot compensate for shortages on another.
Publish rules for cancellations and missing evidence
A customer cancellation before release and a cancellation caused by unavailable stock are different events. Decide which belong in the eligible population, retain the reason and timestamp, and show excluded quantities separately. Removing every canceled line can improve the reported percentage while hiding demand the business failed to supply. Apply the approved rule to historical periods consistently or label a restatement.
Keep unknown shipment status distinct from zero shipped. A missing warehouse feed is missing evidence, while an explicit zero is an observed quantity. Display the count of unresolved lines beside the rate and state whether they are included or excluded. If the denominator is zero, report no eligible demand rather than 0% or 100%; neither percentage describes a period with nothing to measure.
To combine warehouses or weeks, add their eligible numerators and denominators before dividing. Do not average percentages from differently sized populations. Segment the result by customer promise, location, or item family when that distinction helps assign corrective work, but keep the overall population available so a filtered view does not get mistaken for the whole business.
Use the incomplete lines to choose the next investigation
Open the lines that missed the chosen cutoff and check the event sequence. A shortage needs a usable-stock and receipt review; a packed order waiting for a carrier needs a shipping investigation. The stockout investigation covers the first case. Raising every reorder quantity after a low fill-rate result would treat these different causes as the same problem.
Assign an owner and a correction date to each supported cause. Keep the original measurement available after the correction, then compare a later period under the same rules. If physical counts disagree with recorded availability, use inventory reconciliation before changing planning assumptions. The rate locates an outcome; the transaction evidence is what supports a corrective action.
Where Permute fits in a recurring service review
Permute sells connected business data and custom applications. We can scope a recurring service review that connects permitted order and shipment records, resolves item identifiers and units, and applies your approved fulfillment definition. That work starts with a sample whose totals the operations owner can reproduce.
The shared definition can support an operations manager’s view of incomplete lines, source timestamps, and unresolved mappings. A reader should be able to follow a result back to the order and shipment evidence they are permitted to see. Confirm connection coverage, refresh timing, and access requirements for the proposed implementation before replacing an existing report.
Explore a service report on your permitted data
Start with an order export and the shipment events that support its fulfilled quantities.
Keep service policy and operational approvals with their owners
Permute does not choose the customer promise, approve substitutions, or infer missing shipment events. We are not a forecasting engine. An analytical result is not approval to change stock allocations or customer orders; any external action requires a supported workflow, explicit approval, and the relevant permissions. Agree on those requirements separately from reporting.
Calculate fill rate at the level your decision needs, and name that level in the result. Use the same order population and cutoff when comparing unit, line, and order measures. Preserve partial shipments and exclusions so a second reader can reproduce the numbers. Investigate incomplete lines with their source events before changing an inventory or shipping policy.
Review a disputed fulfillment number
Bring the order population, shipment extract, and current calculation to identify where their definitions differ.
Questions about fill-rate reporting
What is a good fill-rate target?
Set the target against the customer promise, item economics, and measurement definition. A unit rate and a complete-order rate are not interchangeable benchmarks. Review the cost and service consequences with the policy owner rather than adopting an uncited industry average.
Should returns reduce fill rate?
Keep the shipment-based definition stable and report returns as a separate quality or acceptance measure unless the agreed service contract includes them. If acceptance is required, name that measure and define the observation period. Do not quietly subtract a later return from an earlier shipment snapshot.
Does a substitute count as a filled line?
Only under an approved rule that identifies acceptable substitutes and preserves customer acceptance where required. Retain the requested and supplied item identifiers. Otherwise a shipment of a different item should remain an exception for review.
Can I calculate this in a spreadsheet?
Yes. Keep one demand row per order line, aggregate shipment events to that line, and apply the same cutoff to the whole sample. Reproduce the worked example before loading a larger extract, and preserve the original files so another reader can check the calculation.