The problem is not the split delivery itself
Split deliveries are normal.
A supplier sends part of the order today, the balance next week. One line is in stock, another is backordered. A product arrives as a substitute. A delivery turns up short. None of that is unusual.
What causes the operational damage is when your purchasing workflow still behaves as if every purchase order follows the same pattern: one order, one delivery, one receipt, then done.
That model breaks quickly in real operations. Jobs consume materials line by line, not purchase order by purchase order. Scheduling depends on what is actually available, not what was ordered. Costing depends on what was actually received and at what cost. Invoicing and handover decisions depend on whether the job can genuinely proceed, not whether a PO exists in the system.
If your workflow only tells you that a PO is "ordered" or "closed", you lose the middle ground where most of the important operational decisions sit.
Ordered does not mean available
This is the core mistake behind a lot of purchasing confusion.
Once a PO has been issued, many teams start treating the materials as effectively handled. The order has been placed, so the job planner assumes stock is coming. The scheduler sees the job as progressing. The project manager expects the install date to hold. Accounts expects the cost to line up with the original order.
But an ordered item is not the same as an available item.
Between those two states, a lot can happen:
- only some items arrive
- some quantities arrive short
- one line is delayed while others are delivered
- the supplier substitutes a different item
- the balance is pushed out without being clearly recorded
- the received quantity does not match the invoice
- the materials arrive, but not in a condition that allows the next stage of work
If the system treats "PO raised" as good enough for downstream decisions, staff start working from assumptions instead of actual supply state.
That is when you get jobs booked without the required materials, teams arriving on site missing a critical component, or office staff discovering too late that only 80% of what was needed is physically there.
Why simple PO statuses fail in practice
A purchase order status like open, received or closed can be useful at a very high level. The problem is that it is too coarse to support the operational decisions that happen downstream.
Consider a PO with six line items for a job. Four lines arrive today. One is partially supplied. One is backordered.
At the PO level, what is the status?
- It is not really unreceived.
- It is not fully received.
- It may not be appropriate to close.
- It may or may not be enough for the job to proceed.
A single PO status cannot answer the questions the business actually needs answered, such as:
- Which items are here?
- Which quantities are still outstanding?
- Is the missing item critical to the next stage of work?
- Has the expected delivery date for the balance changed?
- Has the total expected cost changed?
- Can the job be scheduled, partially progressed or not touched yet?
When those questions are not answered in the workflow itself, people build workarounds around it. They use email threads, handwritten notes, phone calls, spreadsheet trackers or memory.
That is usually where the visibility disappears.
The real unit of control is the line item
If you want purchasing to support operations properly, the workflow has to reflect how fulfilment actually occurs.
That usually means tracking receipt state at the line level, not just at the PO level.
For each line item, you typically need to know:
- ordered quantity
- received quantity
- remaining quantity expected
- whether the line is complete
- whether a substitute was received
- whether the substitute is accepted
- expected delivery date for the outstanding balance
- actual cost if it differs from what was ordered
- whether the line is critical to job readiness
Once you have that, the PO status becomes a summary, not the source of truth.
That matters because two different purchase orders can both be marked "partially received" while representing completely different operational realities. One may be ready for the job to proceed. The other may still be blocked by a single essential item.
Without line-level status, those two situations look the same in the system even though they should drive different actions.
Partial receipts affect more than the purchasing team
A partial receipt is often treated as a procurement detail. In practice, it affects several parts of the business at once.
Scheduling
If the schedule assumes the order is effectively complete, field teams can be booked against a job that cannot actually go ahead.
Sometimes the missing item is minor and the job can still proceed. Sometimes one missing bracket, fitting, panel or component makes the visit pointless. The system needs a way to distinguish between those cases.
Otherwise the scheduler is left chasing the warehouse, the project manager or the supplier manually just to work out whether the booking is still valid.
Job readiness
A job is not ready because a PO exists. It is ready when the required materials for the next stage are actually available and verified.
That sounds obvious, but many workflows never define readiness properly. Instead, the job moves forward because someone assumes purchasing has done its part.
A better model is to tie readiness to the material state required for that stage of work. For example:
- rough-in can proceed with the currently received items
- fit-off cannot proceed until the balance arrives
- install can proceed only if all critical lines are received or approved substitutes are accepted
That logic should be explicit. If it lives only in someone's head, the same confusion will keep repeating.
Costing
Partial receipts also distort job costing when the system assumes the original PO value is the delivered cost.
That becomes a problem when:
- the received quantity differs from what was ordered
- the supplier sends a substitute at a different price
- freight or ancillary items appear across multiple deliveries
- the final cost is spread over several receipt events rather than one
If your costing is updated only when the PO is closed, the job can sit for days or weeks with misleading cost expectations. That affects profitability visibility and can distort decisions about margin, variations or invoice timing.
Invoicing
Some businesses invoice based on job stage completion, some on supply milestones, some after install. In all cases, partial receipts can create trouble if the invoicing workflow assumes material commitments and material availability are the same thing.
You do not want to invoice as if materials were fully supplied when the balance is still outstanding, and you also do not want completed work held up because the system cannot separate received and pending items cleanly.
Substitute items need their own handling
Substitutions are another common point of failure.
A supplier may send an alternative product because the original item is unavailable. Sometimes that is acceptable. Sometimes it is functionally equivalent but needs approval. Sometimes it creates installation issues, warranty concerns or cost changes.
If the receiving process simply marks the line as received without recording that it was substituted, you lose an important decision point.
The workflow should be able to distinguish between:
- original item received as ordered
- substitute received and approved
- substitute received but pending approval
- substitute rejected and replacement still required
That distinction matters because a substitute can make the stock look available while the job is still operationally blocked.
For example, the warehouse may have received the alternative item, but the site team may not be able to use it without client approval or technical sign-off. If the system only sees "received", scheduling and job readiness become unreliable again.
Backorders should update expectations, not just leave the PO open
A lot of purchasing workflows handle backorders badly because they do not convert the receipt event into a meaningful operational update.
The original order remains open, but nobody downstream can easily tell:
- what is still outstanding
- when it is now expected
- whether the schedule should move
- whether the customer should be updated
- whether another supplier should be considered
- whether the job can proceed in a limited way
A backorder is not just a purchasing note. It changes the operating plan.
That means the receiving or procurement workflow should trigger updates to the parts of the business that depend on that information. Not every update needs to be automated, but the trigger should exist.
For example, when a partial receipt is processed, the workflow may need to:
- update the outstanding quantity on each affected line
- store the revised expected date for the remaining balance
- recalculate whether the job is ready for its next stage
- flag any critical shortages to scheduling or operations
- update expected job cost if the received item or price differs
- hold off on closing the PO until completion criteria are actually met
That is far more useful than simply leaving the PO open and expecting staff to remember what that means.
Job readiness needs explicit logic
One of the biggest causes of confusion is when businesses treat job readiness as a vague judgement rather than a defined system state.
A better approach is to decide what readiness actually means for each type of work.
That might include rules such as:
- all critical material lines for the next stage must be fully received
- approved substitutes can count as ready, pending substitutes cannot
- non-critical consumables can remain outstanding without blocking the job
- a partial delivery may allow stage one to proceed but not stage two
- long-lead items must be separately tracked because they control the schedule
This is where many businesses discover that the problem is not their purchasing team. It is that the workflow never defined how purchasing state translates into operational readiness.
If you do not define that logic, every scheduler, project manager and warehouse person ends up making their own call. The result is inconsistency, unnecessary phone calls and jobs moving on false assumptions.
Receiving events should drive schedule and cost updates
A receipt should not just be an inventory or accounts event. It is an operational event.
Something has changed in the real world:
- materials have become available
- some materials have not become available
- expected completion timing may have changed
- expected job cost may have changed
- the next action may now be different
That means your workflow should decide what gets updated when a receipt is recorded.
At a minimum, partial and full receipt events should be able to influence:
- material availability
- job readiness status
- outstanding procurement actions
- schedule confidence
- estimated or committed job cost
- exceptions requiring human review
This does not mean every receipt needs to trigger a complex automation chain. It means the system should not treat receiving as an isolated administrative step.
If a critical item is still missing, the schedule should not continue as if nothing has changed. If a substitute has been accepted, the job should not remain blocked because nobody updated the status manually. If final quantities differ from what was ordered, job cost expectations should reflect that as soon as practical.
Define when a PO is actually ready to close
A PO should not be closed just because the team is tired of looking at it, and it should not remain indefinitely open because nobody defined the rules.
Closing criteria need to reflect the real end state of procurement activity.
A PO might be ready to close when:
- all line items are fully received, or
- remaining quantities have been formally cancelled, or
- substitutions have been accepted and the original lines resolved, or
- short-supplied items have been written off or moved to a new procurement action, or
- any cost discrepancies have been accounted for
The important point is that "close PO" should mean there is no remaining ambiguity.
If a purchase order can be closed while outstanding quantities are still effectively unresolved, downstream reporting becomes unreliable. If it can never be closed without awkward manual cleanup, the team stops trusting the status field altogether.
Neither outcome helps operations.
What a better partial-receipt workflow looks like
A more reliable workflow usually includes a few simple design principles.
1. Track receipt status per line, not just per PO
This is the foundation. Each line should show what was ordered, what was received, what remains outstanding and whether the line is complete.
2. Separate ordered, received and available
An item may be ordered but not received. It may be received but not yet approved for use. It may be received in substitute form and still awaiting a decision.
Those are different states and they matter operationally.
3. Define critical versus non-critical items for job progression
Not every missing item should block the job. But the business needs a consistent rule for what does.
4. Record expected balance and revised dates
If only part of the order arrived, the workflow should capture when the remainder is now expected, not just that it has not arrived yet.
5. Handle substitutions explicitly
A substitute should never disappear into a generic received status if approval or cost treatment still matters.
6. Let receipt events update downstream expectations
Scheduling, readiness and costing should respond to what has actually been received, especially where the missing items affect the next stage of work.
7. Make PO closure a resolved state, not an administrative shortcut
Closing the order should mean the procurement story is finished or properly accounted for.
The goal is not more purchasing detail for its own sake
This is not about creating a more complicated procurement process.
It is about preventing bad assumptions from flowing into scheduling, costing and invoicing.
When the workflow cannot represent split deliveries properly, people compensate manually. They make calls, send chaser emails, keep private notes and create side spreadsheets just to understand what is going on. That is expensive in time, but more importantly it creates avoidable mistakes.
A purchasing workflow should reflect the way materials are actually fulfilled and consumed. If it does not, the business ends up planning work against paperwork rather than reality.
For operations-heavy businesses, that usually shows up as jobs booked too early, incomplete material packs, confused handovers, inaccurate cost expectations and too much reliance on someone remembering the latest supplier update.
Good systems reflect real fulfilment behaviour
The visible issue may look like a supplier sending materials in stages.
The underlying issue is usually that the workflow has no useful way to represent partial fulfilment and turn it into operationally meaningful status.
That is why this problem tends to spread beyond purchasing. It affects readiness, scheduling, job costing and confidence in the system itself.
If your purchase order process breaks whenever deliveries are split, the answer is usually not another status field bolted onto the side. It is stepping back and deciding:
- what the source of truth should be for receipt state
- how line-level quantities should be tracked
- what makes a job genuinely ready
- how substitutions and backorders should be handled
- what events should update scheduling and costing
- when a PO is actually complete
If that workflow runs across multiple teams or systems, mapping it properly before changing software is usually worthwhile. That is the kind of operational design work 5M Consulting helps businesses think through so the process matches the way work really happens.