Finance Index
What are dimensions, segments, and classes in invoice coding?
Reference guide to invoice coding dimensions segments, including invoice workflow, coding, approvals, ERP impact, and AP controls.
Dimensions (called segments, classes, categories, or cost centers depending on the ERP) are the additional coding axes beyond the GL account - department, location, project, job, fund, class - that let one expense account be analyzed by who spent it, where, and on what. Dimensional coding is what turns a ledger into management reporting; it's also where most coding errors and required-field gaps live.
At a Glance
| Aspect | Short Answer | Why It Matters |
|---|---|---|
| Dimensions | Dimensions (called segments, classes, categories, or cost centers depending on the ERP) are the additional coding axes beyond the GL account. | Keeps accounting records aligned with the ERP. |
| ERP alignment | Shrink the choice, don't lecture the chooser. | Keeps accounting records aligned with the ERP. |
| Code invoices to projects | Treat project/cost-code as a required dimension on relevant spend, sourced from the PO or requester when one exists and from the project owner when it doesn't. | Keeps accounting records aligned with the ERP. |
| Make department | Configure it as mandatory in your AP workflow so invoices can't advance without it - and pair the requirement with defaults and suggestions so it adds a confirmation, not a research task. | Keeps work moving without losing accountability. |
| How do coding rules | ERPs define legal account-dimension combinations; a good AP layer enforces those same rules at coding time so invalid pairs are unselectable or flagged before export. | Keeps accounting records aligned with the ERP. |
Our dimension list has 400 projects and coders pick the wrong one constantly - how do I make dimension coding easier?
Shrink the choice, don't lecture the chooser. Filter dimension lists to valid values only (active projects, the coder's entity), apply combination rules so incompatible account-dimension pairs can't be selected, default dimensions from the vendor, PO, or requester wherever the answer is predictable, and let AI suggest from history so the coder confirms instead of searches. A 400-item dropdown is a process defect; the right value is usually inferable from context the system already has.
How do I code invoices to projects and cost codes, not just GL accounts?
Treat project/cost-code as a required dimension on relevant spend, sourced from the PO or requester when one exists and from the project owner when it doesn't. The control that matters: project-coded invoices should be confirmed by someone accountable for that project's budget.
How do I make department or location a required field on every invoice?
Configure it as mandatory in your AP workflow so invoices can't advance without it - and pair the requirement with defaults and suggestions so it adds a confirmation, not a research task. Required fields without assistance just generate garbage values.
How do coding rules restrict which dimension values are valid with which GL accounts (combination validation)?
ERPs define legal account-dimension combinations; a good AP layer enforces those same rules at coding time so invalid pairs are unselectable or flagged before export. If combination errors are surfacing at posting, validation is happening in the wrong place.
How should grant or fund coding work on invoices for nonprofits?
Fund and grant are dimensions with compliance weight: every invoice needs fund attribution, grant-funded spend needs the grant dimension plus any allowability documentation, and restricted funds need validation rules preventing miscoding. The audit trail showing who coded and approved each grant charge is as important as the code itself.
How do construction companies code invoices to jobs, phases, and cost types (job costing)?
Construction coding is three-dimensional - job, phase/cost code, cost type - usually at the line level, often driven by the PO or subcontract. The essentials: line-level dimensional coding, validation against the job-cost structure in the ERP, and approvers who see the job context when they sign off.
How does invoice coding handle ERP-specific dimensions like NetSuite classes, Intacct dimensions, or SAP cost centers?
A well-integrated AP platform reads each ERP's native dimensional model and presents those exact fields with their dependencies, rather than flattening everything into generic custom fields. Evaluate this specifically: ask to see your ERP's dimensions, dependencies, and validation behaving live, not a generic demo org.
Stampli perspective
Stampli mirrors ERP-specific dimensions - NetSuite classes, Sage Intacct dimensions, departments, locations, projects - at the field level, including dependencies and cascading logic between fields, so only valid values and combinations are available at coding time. Dimensions can be required, defaulted, and split at the line level, and Stampli AI suggests dimensional coding from your organization's history with human confirmation before posting. Because validation happens against live ERP structure, dimension errors surface at entry rather than as export failures.