One document, several owners
A printer bills at the end of the month for everything they produced. A freelancer sends one invoice listing four engagements. A media agency reconciles a month of placements across five campaigns.
Each of those is one payable and several project costs. Approving and paying it is straightforward; deciding whose cost it was is a separate question that the approval process never asks.
And because it is never asked, the default answer wins: the whole amount lands somewhere convenient. This page is about making the question answerable at the volume real businesses receive invoices.
Their cycle, your boundaries
The mismatch is structural and permanent. No supplier organises their billing around your project structure, and there is no reason they should.
| The supplier organises by | You need it by | What bridges them |
|---|---|---|
| Their billing month | Project | A reference on the line |
| Their product categories | Project | Line detail plus a rule |
| One contract, many jobs | Project | A split on a recorded basis |
| Delivery batch | Project and site | Delivery address or PO |
Every row in the right-hand column is a piece of information that has to exist somewhere. Where it exists on the document, allocation is mechanical. Where it does not, someone has to supply it — and the difference between those two situations is the entire cost of doing this.
Which references are actually usable
Not all are equal, and knowing the ranking helps you ask for the right thing rather than whatever is easiest for the supplier.
A purchase order number is the strongest, because you generated it. It cannot be mistyped into something ambiguous and it maps to exactly one project by construction.
Your project code in the line description is nearly as good and much more widely available. Suppliers who cannot handle purchase orders will usually type a code into a description field.
A delivery address or site works where projects map to places. Useful for anything physical and useless for services.
A person’s name — who ordered it — is the weakest but not worthless. It narrows the question to someone who can answer it in a sentence.
The critical distinction is line versus header. A header reference only helps when the entire invoice belongs to one project, which is precisely the case that needed no help. A line reference is what makes splitting possible.
Asking suppliers, and what to expect
The highest-return action in this whole area, and one that most businesses never take because it feels like an imposition. It generally is not.
From the supplier’s side, adding your reference to a line costs nothing — the field usually already exists — and it reduces the queries they receive from you, which they value more than you might assume.
Ask when you place work rather than in a general email. “Please put PRJ-114 on the invoice line for this” attached to a specific job gets acted on; a policy announcement sent to a supplier list rarely does.
Start with the suppliers who send the most invoices, not the largest amounts. Volume is what generates the work, and ten suppliers usually account for most of it.
Expect partial success and treat it as a ratchet. Every supplier that starts including a reference permanently removes a monthly decision, and the improvement never reverses.
When the document says nothing
It will, often. Three tools, in order of how much they scale.
A rule against the supplier. This specialist only ever works on one project; this consumable always belongs to one site. Recorded once, applied thereafter — the mechanism is on dimension tagging.
A split on a recorded basis. Where an invoice reliably covers several projects in roughly predictable proportions — hours, units, an agreed percentage. Written down once for that supplier.
A person deciding. Necessary for the residue, and it should be a short list rather than the whole month. If most invoices still need a human after three months, either the rules are not being recorded or nobody has asked the suppliers.
And a fourth option that is legitimate and underused: leaving it in overhead deliberately. A cost that genuinely serves everything should say so, rather than being spread by a rule invented to avoid an awkward blank.
How it works
1 · Upload the invoices
A month or a quarter, up to 100 files at once. Scans and photographs go through OCR first.
2 · Lines extracted
Description, quantity, unit price and line total, read by meaning — so a new supplier needs no template.
3 · Totals reconciled
The sum of the lines is checked against the invoice total, because an allocation built on a misread line is wrong invisibly.
4 · References picked up
A project code, PO number or site in the line is surfaced as a candidate rather than assumed to be correct.
5 · Rules and splits applied
One line becomes several allocated rows where needed, with the basis recorded alongside.
6 · Export
Excel or CSV with the project column, the basis and the source document on every row.
Five supplier types, five treatments
| Type | Typical invoice | Best treatment |
|---|---|---|
| Dedicated specialist | One project per invoice | A rule — no reference needed |
| Production or print | Several jobs, itemised | Line reference; ask if absent |
| Freelancer or contractor | A month across engagements | Line reference, or hours basis |
| Materials supplier | Deliveries across sites | Delivery address or PO |
| Software and utilities | Genuinely shared | Leave in overhead, deliberately |
Classifying suppliers this way once is worth more than handling invoices individually forever. Four of the five types have a treatment that needs no monthly thought, and the fifth is a decision you make once and then stop revisiting.
The third row is the one that quietly consumes the most time in agencies, because a contractor’s monthly invoice is both high-value and genuinely multi-project. It is the first supplier worth asking for line references.
Credit notes and rebills
The most frequently missed documents in project costing, for a simple reason: they arrive separately from the invoice they relate to, often weeks later, and nothing prompts anyone to connect them.
A credit note is a negative allocation against the same project as the original. If it is coded to a general category while the original sat on a project, that project permanently overstates its cost — the opposite of the usual error, and just as wrong.
Rebills are the mirror case: a cost incurred on one project and later recharged to a client or another project. Both sides need recording, or the same money appears twice.
Both are handled the same way as invoices — extracted, referenced where possible, allocated with the basis recorded. What they need extra is a habit of looking for the document they relate to, which is why keeping the original reference visible matters.
Keeping the allocation checkable
An allocation nobody can verify is one that will eventually be disputed and cannot be defended. Four things travel with every row to prevent that.
The source document and page.So “which invoice is this from” is answered by opening a file rather than by searching a folder.
The original line total. Allocated amounts should sum back to it, and when they do not, a split has gone wrong in a way no invoice-level check would catch.
The basis, in words.“Split by hours, per agreement with supplier” can be questioned six months later. A bare percentage cannot.
Where the tag came from— a reference, a rule, or a person. Knowing that an allocation came from a document rather than from someone’s memory changes how much weight it deserves. The full treatment is on entity tagging.
Fitting it into the payables routine
Allocation should happen where invoices are already being handled, not as a separate exercise. A task that stands alone is a task that gets skipped in a busy month, and one skipped month contaminates a quarter of project figures.
The natural point is straight after extraction and before approval. The document is open, someone is already reading it, and the person approving frequently knows which project it belongs to — which is information that evaporates the moment they move on.
Keep the two questions separate in the interface even when they happen together. Approval asks whether to pay; allocation asks whose cost it was. Conflating them means one gets done properly and the other gets defaulted, and it is always the second — the treatment of the first is on three-way match.
Budget ten to twenty minutes a month for the residue once rules are established. If it is consistently taking an hour, the rules are not being recorded.
VAT, discounts and the rounding nobody mentions
Splitting an invoice is arithmetic, and arithmetic on invoices has three complications that are easy to get wrong and tedious to discover later.
Which figure do you allocate? Almost always the net, because that is the cost to the business where VAT is recoverable. Allocating gross inflates every project by the VAT rate and makes projects in different VAT treatments incomparable. Where VAT is not recoverable it genuinely is a cost, and then gross is correct — but that is a decision to make once for the business rather than per invoice.
Invoice-level discounts. A discount applied to the whole invoice belongs to every project on it, proportionally. Leaving it against one project — usually the first line, or a general category — is the most common quiet distortion in allocated data, because the amounts are small enough that nobody checks and consistent enough to bias the same project every time.
Delivery, surcharges and fees. Same treatment as a discount: they belong to the lines they served, spread on the same basis. A delivery charge for a consignment covering two sites is a two-way split, not an overhead.
Rounding. Split any amount three ways and the parts will not sum to the whole. The convention does not matter much — put the remainder on the largest share, or the first — but having a convention does, because without one the difference appears as an unexplained gap between allocated cost and invoice total, and every month someone spends twenty minutes finding it again.
All four are settled once and then stop being decisions. What makes them worth the paragraph is that each of them, left unsettled, produces a small consistent bias rather than a visible error — and a small consistent bias is the hardest thing to find in a dataset.
When an allocation is challenged
Eventually someone will say the cost on their project is wrong. This is a good sign — it means the numbers are being read — and it is worth being ready for, because how the first challenge goes determines whether anyone reads them again.
Three kinds of challenge, and they need different answers. “That is not our cost” is settled by opening the invoice, which is why the source document travels on every row. It is either theirs or it is not, and the conversation is over in a minute.
“That is not our whole cost”is a challenge to the split, and it is settled by the recorded basis. “Split by hours, per the agreement with this supplier” can be discussed on its merits. A bare percentage with no explanation cannot be defended and should not be attempted.
“We should not be carrying that at all” is not an allocation question. It is a question about what the project agreed to absorb, and it should be resolved as one rather than by quietly moving the cost somewhere else. Moving a disputed cost into overhead to end an argument is how overhead becomes the largest and least explicable number in the business.
One habit prevents most of this: when an allocation changes after a challenge, record why alongside the row rather than overwriting it. The second time the same supplier comes up, the reasoning is there and the conversation does not restart from nothing.
Six mistakes
Coding the whole invoice to one project
Overstates one and understates the others, and the total is right so nothing flags it.
Relying on a header reference
It only helps when the whole invoice belongs to one project — the case that was already easy.
Never asking suppliers
The cheapest improvement available, and it permanently removes monthly decisions.
Re-deciding splits each month
The basis drifts, and only a stable basis makes projects comparable to each other.
Missing credit notes
They arrive separately and leave the project overstated — the opposite error, equally wrong.
Allocating during approval without separating the questions
One of the two always gets defaulted, and it is always the allocation.
What this is not
It is not an approval workflow. It does not route invoices, collect sign-off or schedule payment, and it has no opinion about whether an invoice should be paid.
It does not know your projects. The mapping comes from a reference on the document or from you; there is no source of truth for it inside a supplier’s billing system.
It will not guess. Where no reference and no rule apply, the row is presented as needing a decision rather than filled with the most likely project — a confident wrong allocation is worse than a visible blank.
And it does not cover internal time, which in a services business is usually the larger cost. That comes from time tracking, and the boundary is drawn explicitly in the project costing guide.