Which ledger account does this line post to? Replace hard-coded codes with a checked mapping table

A mapping is a decision, so keep it where people can read it

Every posted line needs an account, and which account is an accounting decision, not a programming one. When the decision lives as a code written into a script, a Zap or a hidden sheet column, nobody can review it and the next change of chart breaks it silently. A mapping table is a short, readable list: source category, account, and any tax type or tracking field the sync already sets. Your bookkeeper or accountant approves the rows; the software only follows them.

How hard-coded codes fail

Xero's guidance for integrations says not to rely on the default chart of accounts, because users often customise it or import different account codes, and not to ask users to type account codes. Accounts can be archived, and posting to one returns a validation error saying the code is not valid or has been archived. Accounts can also be renamed or have their code changed. Xero's invoice reference shows an AccountId on invoice line items alongside the AccountCode; that is a reason, in this guide's reasoning rather than a Xero recommendation, to store the identifier and not only the code.

• An archived account usually fails loudly; a catch-all default fails silently.
• A reused code can point an old mapping at a new, unrelated account.
• Draft documents can be saved with incomplete lines, so an error may appear only when a document is approved.

A table that survives chart changes

Key each row by the account's stable identifier and show the current code and name beside it for people. Before each run, or before each call if the integration runs rarely, validate every row against the live chart of accounts: the account must exist, be active and be of a type suitable for the line. Xero says to filter out archived accounts and to send the user back to fix the mapping when an account is missing, instead of continuing. Payment accounts are a separate list, found by account type bank or by the flag that allows payments to the account.

No default account: hold the line

A default account feels safe, but it turns a visible gap into a silent misposting that surfaces at month-end. Instead, a line whose category has no row, or whose account fails the check, posts nothing and appears in a held list naming the category and the account. The rest of the batch still posts. Each run summary shows the held count, and a short procedure says who clears it and how a new category is added.

• Held lines must be counted in every run summary.
• Adding a category is a table edit approved by your accountant, not a code change.

What fits, what does not, and how it is accepted

The fixed-price job "Replace hard-coded account codes in a finance sync with a checked mapping table" is £345 for up to 25 categories. The price is untested, scope is confirmed after your enquiry, and payment follows the agreed checks and your sign-off. It is accepted when every agreed category resolves to exactly one active account, an unmapped category is held, archiving a mapped account holds only its lines while the rest posts, and a code change does not move where a category posts.

It does not choose your accounts, set tax rates or correct history already posted; those stay with your accountant. This guide is written from vendor documentation read on 11 October 2026. Send invented examples and counts first, never credentials, bank details, invoices or customer records; real records are handled only after written agreement through a secure handoff.