Project-Level Invoice Cost Tracking With Custom Fields
Why Can’t Standard Chart of Accounts Coding Track Project Costs?
A chart of accounts is a taxonomy of cost types. Legal fees, professional services, travel, software subscriptions. It answers one question precisely — what was purchased — and is structurally incapable of answering a second one that finance teams need constantly: what was it for?
Two invoices from the same law firm, identical in amount, post to the same account. One relates to a transaction that completed; one relates to one that collapsed. The ledger cannot distinguish them, and no refinement of account structure fixes it, because the distinction is not about the nature of the cost.
Teams respond by attempting to encode purpose into the account structure itself — creating accounts such as “Legal fees — Project Northwind” — and the result is a chart of accounts that grows without limit, breaks comparability across periods, and becomes unmaintainable within a year. Guidance from the Corporate Finance Institute on chart of accounts design is consistent on this point: the account dimension should stay stable and relatively small, with analytical dimensions handled separately.
The correct structure is two dimensions. The account says what. A project or cost-centre field says what for. Custom fields on the invoice record supply the second without touching the first.
What Are Custom Fields in Invoice Processing?
A custom field is a user-defined attribute attached to an invoice or to individual lines on it, captured during processing and carried into reporting and export. Unlike the chart of accounts, custom fields are configured by the finance team to match how the organisation actually thinks about its costs.
Typical fields in practice:
- Project, deal or mandate code — the dominant use case for investment firms, advisory businesses and anyone operating a project P&L
- Entity or subsidiary — where one payables function serves several legal entities
- Cost centre or department — conventional internal allocation
- Client or matter — for businesses that rebill costs onward
- Contract reference — linking spend to a commercial agreement
- Billable flag — whether the cost is recoverable from a client
The attribute that makes custom fields more than a note field is that they are structured, validated and reportable. A project name typed into a free-text comment is not data; a project code selected from a controlled list is. Work by the Institute of Management Accountants on management reporting treats this distinction as foundational: an analytical dimension is only useful if its values are constrained at the point of capture.
Invoice-Level vs Line-Item-Level Custom Fields: When to Use Each
This is the decision most often made carelessly and most expensive to reverse.
| Dimension | Header (invoice) level | Line-item level |
|---|---|---|
| Granularity | One value per invoice | One value per line |
| Best for | Invoices wholly attributable to one project | Invoices spanning multiple projects |
| Typical users | Utilities, single-engagement professional fees | Advisory firms, consolidated monthly billing |
| Data entry effort | Low | Higher, unless extracted automatically |
| Reporting fidelity | Adequate when splits never occur | Accurate under all conditions |
| Risk if wrongly chosen | Split costs collapse to one project, permanently | Minor redundancy when all lines share a value |
| Reversibility | Cannot reconstruct splits retrospectively | Can always aggregate upward |
The asymmetry is the point. Choosing line-item level when every invoice happens to relate to one project costs you a small amount of redundancy. Choosing header level when invoices do span projects loses the allocation permanently, because the information needed to split the invoice existed only at the moment of processing and is gone once the record is approved.
For professional-services spend — legal, consulting, research — multi-project invoices are the norm rather than the exception. A law firm’s monthly bill routinely covers several matters as separate lines. If the project dimension lives only at header level, that detail is destroyed on entry.
The defensible default is line-item level with the ability to apply one value across all lines in a single action, which removes the effort objection while preserving the fidelity.
How Do You Get Project Codes Onto Invoices Without Manual Entry?
The reason project tracking fails is almost never conceptual. It fails because someone has to type the code on every invoice, and under volume that degrades.
Three mechanisms reduce or remove the manual step.
Extraction from the document. Professional-services suppliers frequently print the reference themselves — a matter number, engagement code or project name — because their own billing systems require it. Where that is true, extraction can be configured to read the field and populate the custom field directly. This converts the most labour-intensive case into the most automated one.
Derivation from the vendor. Where a supplier works exclusively on one engagement, the project can default from the vendor master. The default remains editable, but the common case requires no action.
Inheritance from context. Where invoices arrive through a project-specific capture address or carry a consistent reference in the subject line, the value can be assigned at intake.
What remains manual is genuinely ambiguous attribution, which is correct — that is a judgement, and it should be made by a person. Our guide to format-agnostic invoice processing covers how extraction handles inconsistent supplier layouts, and email-based invoice processing delays addresses the intake path.
What Project Cost Data Should You Capture?
More fields is not better. Each mandatory field adds friction, and a field completed inconsistently is worse than one that does not exist, because it produces reports that appear complete and are not.
| Field | Priority | Validation | Why |
|---|---|---|---|
| Project or deal code | Essential | Controlled list of active codes | The primary analytical dimension |
| Entity | Essential in multi-entity structures | Controlled list | Drives statutory reporting and intercompany allocation |
| Cost centre | High | Controlled list | Conventional internal accountability |
| Billable to client | High where rebilling occurs | Boolean | Determines recoverability |
| Contract reference | Medium | Free text or list | Links spend to commitment |
| Phase or stage | Low | Controlled list | Useful only where project phasing drives decisions |
| Approver note | Low | Free text | Context, not reporting data |
The validation column carries most of the weight. Free-text entry produces variant spellings — “Project Northwind”, “Northwind”, “NW-2026” — that fragment every report built on the field. A controlled list of active codes, maintained as projects open and close, keeps the data aggregatable. The maintenance effort is real and is the price of usable reporting.
One related rule: when a project code changes, retire the old value and map to the new one rather than renaming in place. Renaming rewrites history and makes prior-period reports irreproducible, which becomes a problem the first time an auditor asks why last quarter’s figure has moved.
How Do Custom Fields Change Approval Routing?
Once a project dimension exists on the invoice, it becomes available as a routing condition — and this is where the value compounds beyond reporting.
Invoices can route to the owner of the project they are charged to, rather than to a generic approver who has no basis for judging whether the cost was warranted. A project owner knows whether the advisory work was commissioned; a finance approver does not. The same field that enables cost reporting enables materially better approval decisions.
It also improves the approval request itself. Surfacing the project code in the notification means an approver sees what the spend relates to without opening the record, which is the difference between a decision made on a phone and one deferred to the next time they sit at a desk. Research from Gartner on finance technology identifies decision context in the approval request as a stronger determinant of cycle time than the number of approval steps. Our analysis of AP approval workflow automation and approval workflow bottlenecks covers how notification context affects approval latency.
A caution: routing by project only works while the project list is maintained. An invoice coded to a closed project with no active owner stalls silently. Closing a project should include reassigning approval responsibility, not just removing the code from the list.
What Breaks When Project Tracking Lives in Spreadsheets?
The default alternative is a parallel spreadsheet in which someone records which invoice belonged to which project. It works at low volume and fails predictably as volume rises.
| Failure mode | Cause | Consequence |
|---|---|---|
| Drift from the ledger | Spreadsheet updated separately from invoice processing | Project totals stop reconciling to the general ledger |
| Missing recent spend | Update lag between processing and recording | Project reports understate committed cost |
| No line-item granularity | Multi-project invoices recorded as one row | Allocation approximated, then treated as exact |
| Single-owner dependency | One person maintains the mapping | Reporting stops when they are unavailable |
| No audit trail | Cells overwritten without history | Cannot evidence why a cost was attributed as it was |
| Retrospective reconstruction | Attribution inferred months later | Guesswork presented as allocation |
The last row is the real damage. Retrospective attribution — working out in month three which project February’s advisory invoice related to — produces numbers that look authoritative and are substantially estimates. Decisions get made on them. Research from APQC on cost allocation practice finds that organisations capturing attribution at transaction time report materially higher confidence in project profitability than those reconstructing it in reporting cycles.
Capturing the dimension at the point of processing, when the invoice and its context are both in front of someone, is the only point at which the attribution is actually known.
How Peakflo Helps
Peakflo supports custom fields at both invoice and line-item level, configured by the finance team without engineering involvement or change-request fees. Fields can be defined as controlled lists so project codes stay consistent, set as mandatory where attribution is non-negotiable, and marked for extraction so that where a supplier prints a matter or engagement reference on the invoice, the value is read from the document rather than typed.
The same fields feed the rest of the process. They appear in approval notifications, so approvers see what the spend relates to without opening the platform; they operate as conditions in approval rules, so invoices can route to project owners rather than generic approvers; and they export alongside coding and approval history into reporting or an accounting system. For multi-entity structures the entity field works the same way, which is covered further in our guide to AP anomaly detection across multi-entity finance teams. Teams rebilling costs onward can combine the project field with a billable flag, as described in billable client expense rebilling automation. To see field configuration against your own project structure, request a demo.
Our Verdict
Project cost tracking is treated as a reporting problem and is actually a data-capture problem. Every organisation that cannot report project profitability reliably has the same root cause: the attribution was never captured at the point the invoice was processed, and everything after that is reconstruction.
The decisions that determine success are made once, at configuration, and are difficult to revisit. Put the field at line-item level unless you are certain invoices never span projects. Validate against a controlled list rather than accepting free text. Enable extraction wherever suppliers already print the reference. Make it mandatory, because optional attribution fields are completed when convenient and the gaps are exactly where the interesting spend sits.
Be restrained about field count. Three well-maintained fields produce better reporting than eight inconsistently completed ones, and each additional mandatory field is friction applied to every invoice forever.
Where this matters less: organisations whose costs are overwhelmingly general overhead with little project-attributable spend. There the chart of accounts genuinely is sufficient, and adding a project dimension creates maintenance without insight.
Conclusion
The gap between what a ledger records and what finance is asked to explain is where project cost tracking lives. Account codes describe the nature of spend; they were never designed to describe its purpose, and no amount of account proliferation makes them do so.
Custom fields close that gap cheaply, provided the setup decisions are made deliberately. Line-item granularity, controlled vocabularies, automatic extraction where the data already exists on the document, and mandatory completion are what separate a project dimension that supports decisions from one that produces plausible-looking reports nobody fully trusts.
Frequently Asked Questions
Why can’t the chart of accounts track project costs?
The chart of accounts records the nature of a cost, not its purpose. Legal fees post to a legal fees account whether they relate to one deal or another. Tracking by project requires a second dimension alongside the account code, which is what a custom field provides.
Should project codes sit at invoice level or line-item level?
At line-item level if a single invoice can span multiple projects, which is common with advisory and professional-services billing. Header-level fields are simpler and sufficient only where each invoice relates wholly to one project. Choosing header level when splits occur loses the allocation permanently.
Can project codes be extracted from the invoice automatically?
Yes, where the supplier states them. Many professional-services firms print a matter or engagement reference on the invoice, and extraction can be configured to read that field and populate the custom field without manual entry.
How many custom fields is too many?
The constraint is data quality rather than a numeric limit. Every mandatory field adds friction at entry, and fields that are inconsistently completed are worse than absent because they create reporting that looks complete and is not. Start with project, entity and cost centre, and add only when a specific report requires it.
What happens when a project code changes mid-engagement?
Retire the old code rather than renaming it, and map historical records to the new one through a documented relationship. Renaming in place rewrites history and makes prior-period reports irreproducible, which is a problem during audit.
Can custom fields be used to route approvals?
Yes, and it is one of the stronger reasons to implement them. Routing an invoice to the owner of the project it is charged to puts the decision with someone who can judge whether the cost was warranted. Control guidance from IFAC favours routing authority to the person accountable for the budget being consumed.