Split a Supplier Invoice Across Multiple Construction Projects

A builders' merchant delivers steel to two sites on one ticket. A plant-hire company invoices for a telehandler that moved between three jobs in a month. A temporary-services bill covers the welfare cabin and security on every active project. In each case the bookkeeper looking at the invoice has to decide how to split it before posting, and the decision has three parts: which basis the split runs on, what each allocated line carries downstream, and whether the split happens at intake or gets deferred to a journal that someone is going to regret writing.

Done well, the answer is short. To split a supplier invoice across multiple construction projects, allocate each line by the basis that fits the cost — delivery quantities by job for bulk drops, line-by-line assignment when SKUs or per-line addresses tie cleanly to specific projects, and percentage allocation by floor area, scheduled value, or labor hours only when no line-level basis is available. Each allocated line then has to carry the job number, phase, cost code, cost type, retention rate, and a copy of the source documentation so the job-cost report and the CVR/WIP position downstream can be reproduced from the line alone. Posting the parent invoice to one job and redistributing later via journal misstates project profitability and damages the audit trail in ways that take longer to undo than the split itself would have taken to do correctly the first time.

The reason this is its own problem, and not a special case of the generic AP exercise of matching one vendor invoice across multiple purchase orders, is that the construction stack works differently from a procurement stack. Jobs are not POs: a job is an active site with its own budget, its own profit forecast, its own retention pool, and its own PM. Cost codes are not GL accounts: the line still has to land on a GL but the cost code is what links it to the budget it spends from, and a cost code without a job is a dangling reference. Retainage applies unevenly — the retention rate held against subcontract labor is rarely the same as the rate held against material, and on some trades retention is not held at all. And approval ownership sits with the requisitioning project manager on each line, not with a procurement queue that signs off the bill in one stroke. Generic multi-PO content does not address any of this, and treating the construction case as a rebranded version of it is exactly how reporting drifts.

This article is the multi-job split exception. The broader system it sits inside — construction invoice coding by job, phase, and cost code — is what the split fragments when one bill spans more of the system than the system was designed to absorb in a single line. The sections that follow walk through the decision logic of choosing the split basis, the field set every allocated line has to carry, how approvals route when one bill becomes three or four PM reviews, what specifically breaks when the split is deferred, and where the intake step can pull job clues straight off the invoice so the AP team is not rekeying them line by line under close pressure.

---

Choosing the Split Basis: Decision Logic Before Mechanics

The working rule is this: use the most concrete basis the invoice itself supports, and only fall back to percentage allocation when no line-level basis exists. The mistake the SERP is full of is starting at the percentage end — opening Excel, deciding the bill is roughly 60/40 between two jobs, posting it, and moving on. That gets the period closed but throws away information the invoice was already carrying. The right starting question is not "what percentage do I use" but "what is the most specific evidence on this bill that ties costs to jobs, and what does that evidence support."

Four bases cover almost everything an AP team will see, and the order they appear here is roughly the order to try them in.

Line-by-line assignment is the default whenever the invoice carries the evidence to support it. SKU codes, line-item descriptions, and per-line delivery references can map cleanly to specific jobs: line A goes to job 1, line B goes to job 2, and the AP team posts each line to its own destination. Builders' merchants and trade suppliers very often fall here — a line for plasterboard with a delivery address that matches the fit-out site, a line for blockwork with a delivery address that matches the groundworks site, a line for a tool order with a PO reference that ties to the maintenance project. When line-level evidence on a builders' merchant invoice supports the split, reading the lines beats estimating the proportions, and the cost preserves the most information about where it actually came from. This is also the basis that lets you split a vendor bill cleanly across multiple cost codes on multiple jobs, because each line can carry its own cost code rather than inheriting an averaged one.

Quantity-based split is the next step out from line-by-line. The cost is delivered in bulk on one ticket but lands physically on multiple sites, and either the invoice records the quantity per drop or the AP team can reconstruct it from delivery tickets. A 12-cubic-metre concrete pour split across two pours on two sites on the same day is the canonical case. The split basis is the physical quantity that landed on each job, evidenced against signed delivery tickets — not a percentage assumption, and not a single-job posting that pretends the second site never received anything.

Percentage allocation is for costs that are genuinely shared and where no line-level or quantity-level basis exists. Site security spread across active jobs, temporary services and welfare allocated by floor area, scaffolding hire that covers two adjacent buildings, plant hire for equipment that idled across the period and cannot be tied to a specific drop. The drivers a controller will actually use for the percentage split are the ones already in the project setup: floor area where the cost scales with footprint, scheduled value where the cost scales with the contract size, labor hours where the cost scales with how the workforce was deployed, headcount where the cost is a per-person service. Whichever driver you pick, the percentages have to come from a defensible source rather than a feel for the relative size of the jobs.

Time-on-site allocation is the right basis for plant or labor that moved between jobs in the period and where neither line-level evidence nor a stable percentage applies. The split runs on hours or days the asset was on each site, evidenced from plant logs, site logs, or timesheets that a PM has signed. The same basis works for shared labor when the timesheet records cross more than one job in the week the invoice covers.

Whichever basis applies, the test for whether it is defensible is the same: can the allocation be reproduced from documents that live outside the invoice itself? Line-by-line splits should be reconcilable against delivery tickets and the contractor's own job-PO mapping. Quantity splits should be reconcilable against signed tickets per drop. Percentage splits should be reconcilable against the floor-area schedule, the scheduled value, or the timesheet records that drove the percentages. Time-on-site splits should be reconcilable against signed site or plant logs. If the basis cannot be reproduced from supporting evidence, the split is an opinion and a future reviewer will treat it as one.

The basis also has to land each line on the right cost code on the right job, not just the right job alone. Plant hire posted to a job is incomplete until it lands as plant on that job's cost-code structure, and a poorly chosen basis can put the same physical cost on inconsistent codes across jobs — material on one, equipment on another — which then rolls up wrong on every cross-project report. The split is job, phase, and cost code together, not a job-level allocation that quietly inherits whatever code was on the parent.

The trap to keep front of mind is that percentage allocation is the easy default. Reaching for it first is how you allocate one construction invoice across several jobs in five minutes; reaching for it last is how you keep the line-level information the AP team will need three months later when a PM disputes the figure or an auditor asks where the cost came from. Treat percentage allocation as the fallback when the more concrete bases genuinely do not apply, not as the starting point for every shared bill that lands.

---

What Every Allocated Line Must Carry

Once the basis is chosen, the next decision is what travels with each allocated line into the system. The principle is simple and worth holding to: each line should answer "where did this cost come from and which job is paying for it" without anyone going back to the source document. The split line is the unit of truth in every downstream report — job-cost actuals, CVR/WIP, retention schedules, audit packs — so the field set has to be complete the first time. Lines that are missing fields look fine in the bill but break later when someone tries to reconcile, dispute, or release retention against them.

The fields below are the working minimum. Treat them as required on every allocated line, not as nice-to-haves.

Job number. The project the cost lands on. Without it the line cannot reach the job-cost report at all, and an unallocated cost on a shared bill quietly defaults to whichever job the parent invoice carried. The job number is the first field on every line and the one most often missed when AP is splitting under time pressure.

Phase. The project phase or work package — groundworks, frame, M&E, fit-out, snagging. Construction billing routinely fragments by phase, and the same supplier line can hit different phases on the same job: a load of timber for fit-out and a load of timber for first-fix carpentry are the same SKU on the same site at the same time, but they spend from different phase budgets and roll up into different stage valuations.

Cost code. The work-results category the cost belongs to. The MasterFormat standard from the Construction Specifications Institute is the construction industry's standardized language for organizing project documentation, translating design intent into work results that contractors can price, procure, and build. Many US contractors code straight to MasterFormat divisions; UK civil contractors more often use SMM7 or CESMM; many subcontractors and smaller GCs run an internal scheme that maps to whichever standard their accounting system supports. The principle is the same in every scheme: the cost code is what links the line to the budget it spends from. A line without a cost code is a line without a budget link, and the moment the cost lands the budget variance report is wrong.

Cost type. Labor, material, subcontract, equipment, or other. Cost type is what drives which subreports the line lands in (the labor analysis, the material analysis, the equipment recovery report) and how the line is treated for retainage and tax. The same supplier can deliver different cost types on the same invoice — a builders' merchant delivering bagged cement (material) and hiring out a forklift driver for the unload (labor or equipment, depending on contract) — and getting the type wrong on a line bleeds into both retention treatment and the labor cost ratios senior reviewers track.

Requisitioning PM. The project manager who owns the line for approval and ongoing accountability. The PM may differ per allocated line — a single bill that hits three jobs has three PM owners, and the bill cannot be approved as a whole, only line by line by each one. Putting the PM on the line, not just on the parent invoice, is what makes per-line approval routing possible at all.

Site / delivery address. The physical location the cost was consumed at. Where line-level addresses exist on the invoice and do not match the headline ship-to (a builders' merchant invoice billed to head office but delivered to three sites), the line address is the truth and the parent ship-to is the billing convenience. Recording it explicitly on the line means the next reviewer does not have to interpret which line went where.

Delivery ticket reference. The merchant or supplier ticket number tying the line to a physical delivery. This is what makes a line-by-line or quantity-based split defensible in a dispute or an audit later. A line with a ticket reference can be reconciled against a signed copy in the file room or the document store; a line without one is asserted rather than evidenced.

Supplier PO reference. The contractor-side PO number the line draws against, where one exists. PO references on supplier invoices are often the most reliable way to confirm which job a line was raised against, because the contractor's PO system already encodes the job and cost code at the moment the order was placed.

Retention rate and retainage pool. Many contractors apply different retention percentages to material and labor (often holding retention on subcontract labor at 5% and on material at zero), and many head contracts hold retention against trade lines but not against ancillary services. The applicable rate has to ride on the line, and the pool the retention sits in (per-job, per-trade, per-period) has to be identified at the point of allocation. Retention applied generically to the parent invoice and inherited by every line is one of the most common quiet errors in construction AP, and it shows up months or years later when tracking retainage on construction invoices for release becomes the controller's problem. Keeping the rate and the pool on each allocated line at posting time is what prevents that.

Tax treatment if it differs by job or counterparty. UK contractors paying subcontracted labor have to apply CIS deductions where the supplier sits inside the scheme, and the deduction status is set per supplier, not per invoice. Construction services in many EU jurisdictions trigger the domestic reverse charge for VAT, which moves the VAT liability onto the contractor and changes how the line posts. US contractors face sales-tax accrual differences by state and by job site. None of this can be inferred safely from the parent invoice when the split is across more than one job — the tax flag has to be set per line.

Alongside the field set, each line should retain the supporting evidence: the source invoice image (or a reference to it), the corresponding delivery ticket where applicable, and the PO reference. Storing these against the line, not only against the parent, is what makes the line reproducible later. An external auditor or a project reviewer should be able to pull a single line out of the system three months after posting and reconstruct the whole story of that cost without reopening the parent invoice and rebuilding the split from memory.

The operational test is short. Pull any single allocated line from a multi-job split done six months ago and ask whether it tells the story of the cost on its own. If it does, the field set is right. If anyone has to reopen the parent invoice to answer the question — which job, which phase, which code, who approved it, what evidence supports it, what retention rate applies, what tax treatment was used — the split lost information at posting and the system is now carrying the deficit.

---

Routing Approvals When One Bill Becomes Three or Four PM Reviews

A shared supplier invoice that spans three jobs needs three approvals, not one, and the workflow design has to acknowledge that before the bill ever reaches a PM's queue. The first decision the AP team makes is whether to split the bill into per-job allocated lines before review, or to send the parent invoice intact to every relevant PM and ask each of them to approve only the lines they own.

Pre-split routing is cleaner. Each PM sees only the lines that belong to their job, the rejection paths are unambiguous (the PM can decline a line without rejecting the bill), and the approval evidence is per line by construction. The cost is that the AP team has to commit to the split before any PM has reviewed it; if a PM later disputes a line's allocation, the line has to be re-routed to the right owner rather than corrected at the parent level.

Post-split routing — sending the parent invoice to all the relevant PMs at once and asking each of them to approve only their lines — keeps the parent visible and lets PMs flag when a line they think is theirs is actually someone else's. The cost is that every PM is reading lines that don't belong to them, the rejection paths get messy (one PM rejecting another PM's line by accident is a real failure mode in this design), and the per-line approval state has to be reconstructed from per-PM responses rather than read off the workflow.

Pre-split routing is the default in any operation that does construction AP at scale; post-split routing tends to survive only in smaller teams where the AP function and the PMs are close enough that the boundary is policed informally. Either pattern can work when the team commits to it; the failure mode is running both informally on different bills and losing track of which is in use.

Once the routing pattern is set, the next choice is whether the PM reviews run in parallel or in sequence. Parallel routing — every relevant PM reviews their lines at the same time — is the default and the faster path. Sequential routing makes sense only where one PM's decision genuinely constrains another's: most often when a line's cost code is in dispute and one PM has already asked for it to be reclassified, in which case the second PM should not review until the reclassification is resolved. Defaulting to sequential approval because the workflow tool is set up that way is one of the easier reasons a multi-job bill ages past its payment date for no operational reason.

Single-line rejections need a clear escalation path defined before the rejection happens, not invented during it. There are three working options when a PM declines a line: send the line back to the supplier for credit (correct treatment when the line should not have been billed at all, or was billed at the wrong price), reassign the line to a different job or a different cost code with a second PM's approval (correct treatment when the line is legitimate but was allocated incorrectly), or hold the parent invoice from posting until the dispute resolves (correct treatment when the rest of the bill cannot move forward without the disputed line being settled). The wrong outcome is a partial post — the bill goes through with the rejected line orphaned, sitting in a held state that no one is tracking, until the period close surfaces it.

The system constraint a lot of construction AP teams run into here is that the accounting platform does not support per-line approvals on a single bill at all. Forum threads on QuickBooks and Sage Construction & Real Estate are full of bookkeepers asking how to do something the platform does not natively offer cleanly, and the answers tend to involve workarounds — Class tracking, billable-expense flags, or splitting the bill into multiple system-level bills with one PM owner each. When the system cannot carry the workflow, the workflow has to compensate. The two patterns that work in practice are explicit written sign-offs per line stored against the line as evidence (a PDF of the PM's email approving the specific line, or a workflow-tool entry that the AP team manually attaches), and physical multiple-bill splits where the AP team accepts the data-duplication cost in exchange for an approval trail the system can actually represent. Neither is ideal. Both beat the alternative of approving the parent invoice once and treating the line-level allocation as untouchable afterwards.

One detail worth getting right whichever routing pattern is in use: when a bill goes back for revision — a PM rejects a line, AP edits the allocation, the bill re-enters the workflow — the prior approval state and the supporting evidence on the surviving lines should remain attached, not be wiped on the new submission. The next reviewer needs to see what changed, who approved what previously, and which lines are coming to them with prior PM sign-off intact. A workflow that resets to a clean parent on each revision loses the audit trail of the changes themselves, and the AP team ends up reconstructing the history of the bill from email rather than from the system of record.

---

What Breaks When Finance Defers the Split

The anti-pattern is worth naming out loud because it is the most common failure mode in construction AP and the one practitioners are most often pressured into: post the entire invoice to one job — usually the largest active project, on the theory that a small misallocation against a big number is hard to spot — and plan to redistribute the cost via journal at month-end, or whenever the project report runs wrong enough that someone notices. Forum threads from QuickBooks and Sage users describe this workflow in detail, sometimes with the bookkeeper asking the community how to do it less badly. It does not deserve to be done less badly. It deserves to be replaced.

Four things break, and each one breaks in a specific way that matters to a different reader of the resulting numbers.

Cost-value reconciliation and WIP misstatement. The cost lands on the wrong project and inflates that job's actual-to-date while leaving another job's actuals understated. Both jobs' CVR positions are wrong from the moment the bill posts, and they stay wrong until the journal redistribution actually runs — which is almost always after the period the misallocation affected has closed. By that point, monthly reporting has already gone out with the wrong figures, the WIP balance has already been struck on a faulty cost base, and the explanation that has to be written into the next variance commentary is a worse use of senior time than the split would have been. The mechanics of the broader CVR cycle and how cost actuals feed it are covered in our cost value reconciliation workbook for construction; the point here is narrower — a deferred split breaks the input.

False project profitability. One job appears profitable because costs it should be carrying are sitting on a neighbor; the neighbor appears to be hemorrhaging margin for no operational reason. Senior reviewers, owners, and external stakeholders who look at per-job profitability between the original posting and the redistribution journal will see the wrong numbers. Some of them will act on those numbers — pulling resources off the apparently struggling job to support the apparently profitable one, calling a profit position into the forecast that does not exist, or escalating margin issues on a project that is in fact running cleanly. The redistribution journal that arrives later corrects the figures in the system but cannot retract decisions made on the earlier output.

Retention applied to the wrong project. Retention is held against the cost line, so a deferred split holds retention on the job the bill was originally posted to, not the jobs the cost actually belonged to. Reversing this later is mechanically possible but operationally fragile: the retention release on the correct jobs will be missed if the original retention entry on the wrong job is not also reversed, and the retention exposure ends up sitting on a project that should already be closed. Retention errors are also the kind of error that surfaces years after they were made, when the original bookkeeper has moved on and no one currently in the role remembers the journal that created the misalignment.

Audit-trail damage. A journal redistribution that follows a deferred split lacks the line-level evidence chain a re-extracted invoice would have. The original posting was a single line to one job, with the parent invoice attached as evidence; the corrective journal is a movement between jobs with a written explanation but no per-line delivery tickets, no PO references, and no PM sign-off on the destination jobs. External auditors reading this chain see a primary entry that was wrong on the available evidence, and a corrective entry that is not supported by primary evidence at all. The pattern reads to an experienced reviewer as a control weakness — the AP function knew the bill spanned multiple jobs but posted it as if it did not — and is the kind of finding that surfaces in a management letter even when the underlying numbers ultimately resolve.

The defense practitioners offer for the deferred split is almost always the period close: there isn't time to do it correctly first time, the bill arrives late, the PMs are not available to approve, the close window is closing. The honest counter is that the time the split would have taken at intake is roughly the time the journal redistribution takes later, plus the time chasing PMs after the fact to confirm allocations the bill never asked them to confirm in the first place, plus the time spent explaining the corrective journal to a reviewer who would not have asked any questions about a clean posting. Across the full cycle, the deferred split is rarely faster. It just shifts the work past the close, which is sometimes confused with saving it.

The only version of this workflow that stays cheap is the one where the split happens once, at intake, with the basis chosen and the field-level metadata captured before the bill posts. Everything else is a downstream cost dressed as a shortcut.

---

Pulling Split-Relevant Fields Off the Invoice at Intake

The invoices that drive this whole workflow already carry most of the information the AP team needs to allocate them. A builders' merchant bill commonly records a delivery address per line, a merchant reference per line, and a description that includes the SKU, the quantity, and often the site the order was placed against. A plant-hire invoice typically lists the asset, the on-hire and off-hire dates, and the site or PO the asset was raised under. A subcontractor invoice carries a per-line scope description that maps to the work package the labor served. The fields needed to choose a basis and to populate every line in section three are sitting on the page already. The actual problem the AP team has is getting them off the page reliably, line by line, before the bill posts — not deciding what to capture in principle.

A well-designed intake step pulls a small but specific set of fields from a multi-job supplier invoice:

• Per-line delivery address or site reference, where the supplier records it on the line rather than only on the header.
• Per-line merchant or supplier PO reference, which is often the most reliable way to identify which job a line was raised against.
• Per-line SKU or product code, with the description, so line-by-line job assignment becomes feasible against the contractor's own job-PO mapping.
• Quantities per line, for quantity-based splits across multiple drops on the same ticket.
• Header-level fields the split still depends on — supplier identity, invoice date, gross and net totals, and tax broken out by treatment so CIS, reverse charge, or state-specific accruals can be applied correctly per line afterwards.

When those fields land on the line at intake rather than being rekeyed afterwards, the rest of this article gets cheaper to execute. Choosing the basis becomes mechanical: line-by-line assignment is feasible whenever the line-level evidence is present, and the team only falls back to percentage allocation when the invoice genuinely lacks line-level signal. The field-preservation requirement is met by construction, because the fields ride on the line as a result of how the line was captured. PM routing is straightforward because every line has the per-line evidence (delivery address, PO reference) that a PM needs to confirm the line belongs on their job. And the deferred-split anti-pattern loses its operational excuse, because the close-window pressure that drives it disappears when the data is already on the line by the time the bill enters the workflow.

This is the natural answer to the question "how do we get the split-relevant fields off the invoice in the first place," and it is also where AI-powered invoice data extraction for construction AP earns its keep on this specific workflow. Invoice Data Extraction is built around a single intake step: a contractor's AP team uploads a batch of supplier invoices, writes a natural-language prompt naming the fields the multi-job split workflow needs (line description, SKU, quantity, line total, per-line delivery address where present, per-line PO reference, header-level supplier and date and tax fields, with the header fields repeated on each line so the row carries everything an allocated line later needs), and downloads a structured XLSX, CSV, or JSON file with one row per line item. The platform supports batches up to 6,000 files per job and single PDFs up to 5,000 pages, which matters in construction AP where merchant statements and consolidated subcontractor packs routinely run long. Each output row carries a reference to the source file and page so any line can be cross-referenced to the original invoice without manual lookup. None of this is generic AP automation; it is intake-side extraction shaped to the data the multi-job split workflow needs.

This article scopes tightly to the multi-job split itself; for the wider construction-AP picture — supplier onboarding, period-close cycles, and how invoice extraction sits inside the broader stack — see automating invoice data extraction for construction companies.

The takeaway for an AP function looking at this workflow is short. The multi-job split is hard when the team has to rekey job clues from the invoice page, line by line, under close pressure, and easy to do badly when that pressure is real. It gets meaningfully cheaper, and significantly more defensible, when those clues come off the page at intake and land on the line before the bill enters the system. The split decisions in section two and the field discipline in section three only stay tractable if the data they depend on is already present at the moment the bill is allocated.