Tax groups
A tax group is a VAT rate.
| Field | Notes |
|---|---|
| ID | The tax value itself — 14, 0, NonTaxable — not a generated identifier. |
| Name | The human label, such as 14 %. |
The identifier is the value, and it is fixed at creation. Other parts of the system carry it as the sales tax group on invoices and read the VAT percentage straight off it.
That has one important consequence: you cannot change a tax group's rate by editing it. When a rate changes, create a new group for the new rate and point future invoice types at it. Editing would silently restate tax on historic documents.
Tax groups are referenced by invoice types and vendor invoices — see Invoice types.
Tariff codes
A tariff code classifies a charge for accounting purposes and can carry its own posting rules.
| Field | Notes |
|---|---|
| Code | The identifier. |
| Name, Description | What it covers. |
| Status | Whether it is in use. |
| Postable | Whether it may be posted to. |
| Type | Which side of the ledger it may be used on — at least one is required. |
| Applicable invoice types | Restricts it to certain customer invoice types. |
| Applicable vendor invoice types | Restricts it to certain supplier invoice types. |
| Applicable custody types | Restricts it to certain custody types. |
Two things to know
A code is unique per set of types, not globally. The same code can exist once as receivable and once as payable. That is deliberate — the same economic charge has two sides — but it means seeing a familiar code does not tell you which one you are looking at. Check the type.
Empty applicability means unrestricted. Leaving the applicable-types lists empty makes a code available everywhere, which is usually right for general codes and wrong for specific ones. Restrict deliberately: an unrestricted specialised code turns up in dropdowns where it makes no sense and will eventually be picked.
Tariff codes are also the scope for tariff-specific posting rules — see Posting rules.
Exchange rates
Finance → Change rate maintains currency conversion.
| Field | Notes |
|---|---|
| Amount | The base amount. |
| Rate | The conversion rate. |
| Version | The rate's version. |
There is also a convert screen for one-off conversions.
Rates are versioned rather than overwritten, which is what allows a historic transaction to keep the rate that applied when it was posted. Journal lines store both the transaction amount and the functional amount, so once a line is posted its translation is fixed — see Journals.
Update rates on a defined schedule and by a defined source. An organisation where several people update rates ad hoc from different websites will not be able to explain its translation differences.
Accounting configuration
Finance → Accounting configuration holds the default account mappings the ledger uses when no more specific instruction exists.
| Key | Used for |
|---|---|
| Global GL account | The fallback account. |
| Cash | Cash movements. |
| Bank | Bank movements. |
| Received cheque | Cheques in hand. |
| Deposited cheque | Cheques presented. |
| Cleared cheque | Cheques settled. |
| Bounced cheque | Cheques returned. |
The four cheque keys are what give the cheque lifecycle its accounting meaning — each status change posts to the account configured for it. See Bank, treasury and cheques.
Configuration can be set globally or per tariff, so a specific class of charge can override the default mapping while everything else follows it.
Treat this screen as sensitive
Every key here affects postings that have not happened yet, across the whole ledger. A wrong mapping does not fail — it posts to the wrong account, quietly, until someone reconciles.
Before changing anything:
- Know which rules and events depend on the key.
- Change it at a period boundary wherever possible, so the before and after are cleanly separated.
- Post a test transaction and check the resulting journal lines.
- Write down why, with the date. Someone will ask.
Last updated 15 September 2026