Most tax work starts as a data exercise. The extract used to be something a person checked by eye. Now it can be pulled monthly, or on demand, through automated pipelines. The end-to-end process has a well-known weakness, summed up as "garbage in, garbage out". But fewer people ask how to make the input less bad at source. In this article, I propose five questions to settle with the data teams before the first table is aggregated.
1. Where does it come from?
That table you download every month from the ERP (enterprise resource planning) system, do you know where and how it was built? The tax team is usually the last stop on a long pipe, and the people who own the data upstream often do not know tax is a customer, or the unique requirements from tax. Find out who they are now. When a number looks wrong in month nine, a name is more useful than a ticket number alone.
2. Which version are you looking at?
Problems can start at source, but the harder ones tend to get in later, through an extract, a mapping or a manual adjustment. Between the ledger and the tax spreadsheet, how many hands touched the data, what did they change, and when? For a provision, which approved trial balance did it use, and how were consolidation adjustments treated? Has that changed since last quarter? Aggregate without knowing, the data view could inherit changes without records, which results in difficult questions to answer in an audit.
3. Is there a data dictionary?
Does everyone agree what each field means? A transaction carries several dates: order, invoice, shipment, payment, posting. Which of them drives when VAT or GST is accounted for depends on factors such as the jurisdiction and the kind of supply, so a column labelled "Date" is not enough. Another example is "Profit". Is it under local accounting rules or group? A figure can be right in the local accounts and still be the wrong input for a view built on the group basis.
4. What controls run with each update?
The first three questions are preventative. Well-thought controls should thus be relied upon to run with every data feed. If an overnight job fails and the feed is stale, does the tax team know? Who picks up the missing, duplicate or unmapped records? Who watches for a rule change and tells the data team what it alters? And when an auditor or a tax authority asks how a figure was produced, can you show the inputs and the rules as they stood that day, and get the same number again? If the answer is "it depends", you do not have a defensible process yet.
5. At what level is it aggregated?
Aggregation inevitably hides details away, which carries risks for tax. A group figure is the wrong input when the rule needs entity detail. Before any transformation, agree the most granular level the tax team will need, keep the rows at that level for the retention period, and document the route from any total back to them. When tax rules change mid-period, transactions before and after the date need different treatment. With the rows kept, and the right date on each, the figure can be recomputed from the change date and reconciled to what was filed.
AI can help with a lot of the legwork. An agent, properly configured with guardrails, could draft a data dictionary from column names and sample values, or read the pipeline code and sketch the lineage. An agent could also propose which date drives the tax, which trial balance feeds the provision, or whether the controls are enough. But the ultimate decision should still stay with the taxpayers who bear the risk.