Skip to main content
Accounting codes map your payroll to a Chart of Accounts. Accounting code rules assign those codes to line items automatically, so each payroll produces a complete journal entry.

Accounting codes

Each accounting code represents one account in the business entity’s Chart of Accounts and is typed as an expense, a liability, or a bank code.
A business’s Chart of Accounts is the list of accounts it tracks money in, each with a short reference like 6000 for Wages Expense. Accounting software often calls these GL codes (general ledger codes). An accounting code represents one of those accounts in Nmbr, typed expense, liability, or bank.
Accounting codes are created at the Business Entity level. Create them through the API, or import them from a connected accounting platform’s Chart of Accounts (see Importing the Chart of Accounts). Fields: See the Accounting Codes API reference for full details.

Merging accounting codes

Duplicate codes can accumulate, often after importing a Chart of Accounts. Send the codes to absorb to POST /accounting_codes/{id}/merge to merge them into one; their references are reassigned to the target code and the duplicates are removed. All codes in a merge must share the same type and Business Entity.

Routing line items to accounts

Accounting code rules decide which expense and liability codes a line item receives. A rule is defined on a Business Entity and assigns an expense_accounting_code and a liability_accounting_code to the line items it matches. A rule matches on any combination of:
  • type (e.g. earning, deduction), optionally narrowed by subtypes (e.g. salary, wage)
  • business_preset_id, the highest-specificity match, mutually exclusive with type/subtypes
  • a tag (tag_id) or any tag from a group (tag_group_id), for tag-scoped routing. Tag-scoped rules match tags in the primary tag group.
A rule with neither a tag nor a tag group is global: it routes every matching line item regardless of tags. A global rule can also carry a segment template instead of an accounting code, to compose a custom code on the Journal Entry report. See Journal Entry Segment Templates. See the Accounting Code Rules API reference for full details.

Covering several subtypes with one rule

subtypes is a set: one rule routes every line item whose subtype is a member of it, so a single code covering salary, wage and commission is one rule rather than three. Every subtype in the set must belong to the rule’s type — a rule never spans more than one type, so a code that also catches deductions needs a second rule. Sending subtypes replaces the whole set; there is no add-one or remove-one. Two rules can carry the same subtype when they match different line items — one scoped to a tag and one global, or two scoped to different tags. What is rejected is a pair that would match the same line item: within one scope (the same tag, the same tag group, or both global) and one type, a subtype belongs to at most one rule, since nothing would decide which of them routes it.
Deprecated: subtype is replaced by subtypes and will be removed in a future release. It still reads and writes, meaning a one-member set, and is still returned as the set’s first member. Sending it against a rule holding several subtypes is rejected rather than dropping the rest.

Example: route salary, wage and commission earnings

Rule precedence

The expense and liability codes are resolved independently. A single line item can take its expense code from one rule and its liability code from another; each side walks the precedence order on its own and uses the first rule that supplies that code. Rules are tried most-specific first. If no rule matches the line item at one precedence, the next precedence is tried: The catch-all (precedence 12) is the default for line items no other rule matches. It is a single global rule, so you can set one default instead of one rule per type. Create it by leaving tag_id, tag_group_id, type, subtypes, and business_preset_id all unset. At most one catch-all exists per business entity. Tag and tag-group tiers (precedences 1–8) apply only to tags in the primary tag group. See Tagging for how tags scope rules.
Rules are re-evaluated whenever a draft payroll is recalculated, so rule changes take effect on the next calculation. Approved payrolls keep the codes they resolved at approval time.
The resolved codes appear on the rows of each payroll’s journal entries. When a line item resolves no code, the entry’s validation flags name what’s missing.

Business Entity accounting settings

Each Business Entity carries an accounting_settings object that holds its accounting configuration. The matching top-level fields (default_bank_accounting_code, default_payroll_payable_accounting_code, primary_tag_group, resolve_journal_entry_stat_withholdings) are retained as deprecated aliases. Set the defaults by updating the Business Entity:
Journal entries still generate without the default bank and payroll payable codes, but they are incomplete: the bank and payable rows carry no accounting code, the entry’s validation flags are raised, and the export is blocked.

Deprecations

GL Codes. Nmbr previously supported a simplified GL Code entity, deprecated in favour of accounting codes. References to “GL Codes” in the API or docs are deprecated and will be removed in a future release. Fallback mappings. Accounting codes previously carried fallback_mappings, a collection of { type, subtype } pairs used to route line items with no explicit code. This is deprecated in favour of global accounting code rules, which cover the same routing and more. The fallback_mappings field still reads and writes for backwards compatibility.