Mappings are the layer that turns a business event into an accounting entry. They are the reason nobody has to write journals for ordinary trading.
What gets mapped
Three kinds.
Expense categories. The category on an expense decides which account the cost lands in.
Revenue sources. What kind of income an invoice represents decides which revenue account it credits.
Payroll components. Salary, allowances, deductions and employer costs each route to their own account.
It comes seeded
This is not a screen you build from nothing. Sensible defaults are set up when the accounting engine is installed, so ordinary trading posts correctly from day one.
You land here for two reasons: something failed to resolve an account and needs telling where to go, or the default is not how your organisation classifies that thing.
That framing matters. This is an inspection and override surface, and an organisation whose chart of accounts matches the default shape may never need to open it.
When something fails to resolve
An event that cannot find an account is the case this surface exists for.
The usual cause is a new category. Somebody adds an expense category in a settings screen, uses it, and nothing here knows where it belongs.
The fix is one row. The lesson is that adding a category is an accounting decision, and the person adding it is frequently not the person who thinks about accounts.
Expense categories
The largest of the three kinds and the one that changes most, because categories are added by people who are not thinking about accounts.
The practical arrangement: whoever owns the books reviews new categories periodically rather than expecting the person adding one to map it. A category unmapped for a fortnight costs nothing; a category mapped wrongly by somebody guessing costs a quarter of slightly wrong statements.
Getting mappings right
Map to the account you would have chosen by hand. If you would post software subscriptions to a software account, map them there. The mapping is not a place to be clever.
Do not map two very different things to one account for convenience. It saves a row now and makes the profit and loss less useful permanently.
Do not create an account per category either. The chart of accounts article covers the balance: accounts are for distinctions that change decisions, categories are for detail.
Payroll components
The third kind, and the one most often misconfigured, because payroll has more moving parts than the other two.
Salary, each allowance, each deduction, and the employer's own costs all route separately. Mapping them all to one account produces a payroll figure that is technically correct and useless: you cannot tell what the organisation actually spends on people versus what it withholds on their behalf.
Withheld amounts in particular are a liability rather than a cost. Mapping them as an expense overstates what payroll costs you and hides what you owe.
Changing one
A mapping applies to postings made after the change. It does not go back and re-post history.
That is correct and worth understanding: a mapping corrected in June does not fix January's statements, and if January is materially wrong the fix is a journal entry rather than a mapping change.
For anything material, correct the mapping and post an adjustment for the period already affected.
Revenue sources
The invoicing side of the mapping, and the one that shapes your profit and loss most directly.
The distinction worth making is by what you sell rather than by who you sold it to. Revenue split by customer is a report; revenue split into product, services and recurring is a profit and loss that tells you what the business actually does.
Two or three revenue accounts is usually right. More than five and the statement stops being readable.
Reviewing them
Once a year, alongside the chart of accounts, and it takes half an hour.
Look for categories with no mapping, which are the ones producing exceptions.
Look for accounts receiving things you would not expect, which usually means a mapping was set once and the category's meaning drifted.
Look at whatever your generic or miscellaneous account received. That is where everything unmapped accumulates, and a large balance there is a list of decisions nobody made.
Where categories are defined
The categories being mapped are not created here. Expense categories live with expenses, revenue sources with the invoice configuration, payroll components with payroll.
This surface only answers where each one posts. That separation is why a new category appears here unmapped rather than being impossible to create: the person adding a category should not be blocked on an accounting decision, and the accounting decision should not be made by accident.
Testing a mapping
The cheap way to check a mapping is right is to use it once and look.
Raise a small expense in the category, approve it, and open the account you expect it to have hit. Two minutes, and it is considerably more reliable than reasoning about the configuration.
Worth doing for every mapping you add by hand, because the failure is silent: a wrongly mapped category posts happily and produces a statement that is wrong in a way nobody notices for a quarter.
The exception account
Anything that cannot resolve lands somewhere generic rather than failing.
That is the right behaviour, since refusing to post a transaction because a category is unmapped would stop the business rather than the bookkeeping. It does mean the generic account quietly accumulates, and it is the first place to look when the profit and loss has a line nobody recognises.
Why this layer exists at all
The alternative is either journal entries by hand, which nobody sustains, or an accounting system that guesses, which is worse.
A mapping layer makes the guess explicit and editable. The system posts automatically, and when it gets something wrong you can see exactly why and change it in one place rather than correcting every future transaction individually.
That is the difference between automation you can trust and automation you have to check.
Did this answer your question?
No, ask a person