How tax processing is set up in finance and ERP systems

In most organisations the ERP calculates and posts transaction taxes through tax codes attached to each invoice line. Income tax, deferred tax and filed returns usually live in separate provision and compliance tools fed from the general ledger. The tax team works in the gap between them, reconciling and adjusting.

Where transaction taxes get decided

Sales tax, VAT and similar levies are determined at the moment a document is created. The ERP looks at the ship-from and ship-to addresses, the product or service classification and the customer or supplier status. It then picks a tax code. That code carries a rate and points to the ledger accounts where the tax will land.

Smaller setups maintain these rules directly in the ERP. Larger or more international businesses often bolt on an external tax engine. The ERP sends the transaction details out, the engine returns the rate and jurisdiction, and the ERP stores the result. The engine keeps rates current. Somebody in-house still owns the product mappings and exemption certificates, and that ownership is frequently unclear.

Withholding on supplier payments follows similar logic but sits in the payables module. Vendor master data drives it. If the vendor record is wrong, the deduction is wrong, and nobody notices until a certificate or a return fails to match.

The ledger as the tax record

Every tax amount ends up in dedicated balance sheet accounts: output tax, input tax, withholding payable, current income tax payable, deferred tax assets and liabilities. Good charts of accounts split these by jurisdiction or by tax type. Poor ones lump them together, which forces manual analysis every time a return is due.

Tax payments themselves are usually raised as payables against a tax authority vendor. Treasury releases the cash. The clearing entry should bring the liability account back to zero for that period, and a lingering balance is the first clue that something was filed differently from what was booked.

Provision and deferred tax

Income tax rarely gets calculated inside the ERP. At period close, trial balance data is extracted into a provision tool or a controlled workbook. The tax team maps accounts to tax categories, identifies permanent and temporary differences, and applies statutory rates.

Deferred tax comes from comparing book and tax bases for assets and liabilities. Fixed assets are the usual heavy item. Many ERPs can run a parallel tax depreciation book, which saves considerable effort when it is maintained properly. When it is not, the tax basis gets rebuilt outside the system each cycle.

The provision output returns to the ledger as journal entries, often posted manually or through an upload. Those entries need review and approval like any other material adjustment.

Returns, foreign filings and the calendar

Indirect tax returns draw on reports from the tax-coded transactions. Some engines produce filing-ready output. Elsewhere, staff export the data, reconcile it to the ledger and key figures into authority portals.

Corporate income tax returns are prepared in specialist compliance software or by an outside adviser, using the provision workpapers as a starting point. Foreign subsidiaries add local returns, transfer pricing documentation and sometimes e-invoicing or real-time reporting rules that reach right back into how invoices are generated. Local advisers commonly prepare these. Head office then struggles to see status.

A compliance calendar, whether a dedicated tool or a shared tracker, lists each obligation with its owner and due date. Monitoring compliance mostly means watching that calendar and checking that filed figures tie back to the books.

Planning and inquiries

Tax planning sits largely outside systems. It shows up in the ERP only when a decision changes structure: a new legal entity, a revised intercompany flow, a different invoicing location. Each of those needs new tax codes, new determination rules and sometimes new ledger accounts. Planning that ignores this configuration work creates compliance problems later.

Notices and audit requests from authorities arrive by letter, email or portal. Responding means pulling transaction detail, contracts and prior workpapers. Teams that keep an organised archive of filed returns with supporting reconciliations answer quickly. Teams that do not end up rebuilding history from raw ERP extracts.

Questions to ask the people who run it

• Which tax codes do people actually pick by hand, and why do they override the default?
• When the tax engine and the ledger disagree, who fixes it and where?
• What gets adjusted in spreadsheets after the system report runs, before a return is filed?
• How do new products or new customer types get a tax classification, and who approves it?
• Is the tax depreciation book trusted, or rebuilt each close?
• Which foreign filings can head office see the status of today?
• Where are past returns and their workings kept, and could someone else find them?
• What happened the last time an authority asked a question, and how long did the search for evidence feel?

The answers to these usually reveal undocumented workarounds that any redesign must either absorb or remove.

Where changes tend to break things

Altering the chart of accounts without updating provision mappings is a common failure. So is migrating ERPs and carrying over tax codes that were already wrong. E-invoicing mandates catch teams out because they touch billing, master data and the tax function at once. Any change to how invoices are created deserves a tax review before it goes live, not after the first return comes out wrong.

APQC's Process Classification Framework® (PCF) is an open standard developed by APQC, a nonprofit that promotes benchmarking and best practices worldwide. To download the full PCF or to view definitions and measures, please visit www.apqc.org/pcf.