An operating model that keeps entity, residency, transaction and reporting data usable across cross-border tax work.
Tax reporting is a data chain with legal consequences
Cross-border tax work draws on facts owned by different teams: legal-entity status, ownership, tax residence, accounting results, headcount, assets, intercompany transactions, financing, and local filings. The tax team may assemble the conclusion, but it rarely controls every input. When the source is a spreadsheet maintained by a different function, the work can look complete while a key assumption has changed unnoticed.
The first question is not “what is the number?”
Ask: what does this number represent, for which entity and period, from which source, under which definition, and who can approve a change? Those questions are practical controls. They do not determine the tax treatment; they make the treatment reviewable by qualified advisers.
Do not collapse different regimes
CRS, FATCA, transfer pricing documentation, country-by-country reporting, VAT, withholding, and local corporate-tax returns have different scopes and data definitions. A shared entity record can connect them, but it should not imply that one classification or deadline answers every regime.
Assign facts before assigning calculations
Build a tax data dictionary that names the owner and source for the facts most likely to change. For an entity group, that may include legal status, ownership and control, tax residence, permanent-establishment indicators, accounting period, consolidation status, intercompany flows, employees, tangible assets, and filing obligations. The owner is accountable for keeping the fact current; the tax reviewer remains accountable for using it appropriately.
- Record the definition and period alongside the value.
- Link to the source document or system record, not just a pasted number.
- Capture changes with effective date, reason, and reviewer.
- Make unresolved or estimated values visible before a report is produced.
- Keep the adviser’s conclusion distinct from the underlying business fact.
Reconcile populations, not just totals
A total can reconcile while the population is wrong. For example, a group may have the right aggregate revenue but omit a newly acquired entity, classify a dormant company inconsistently, or allocate a transaction to the wrong jurisdiction. Reconcile the list of entities and reporting accounts first, then reconcile values and transformations. OECD Country-by-Country Reporting materials emphasize jurisdiction-level information about revenue, profit, tax, and economic activity; those fields are useful only when the underlying population and definitions are controlled.
Keep transformations explainable
When a ledger value becomes a report value, retain the mapping, calculation, adjustment, and reviewer. A spreadsheet can perform a calculation; it should not be the only place where the transformation exists.
Make the review boundary explicit
Software can organize evidence, compare populations, flag changes, and prepare a work queue. It cannot decide a jurisdiction-specific tax position without the relevant facts, law, and professional judgment. Route uncertain matters to qualified tax counsel or advisers, and record the question and conclusion in the matter file. The operational system should make that handoff visible rather than presenting an analytical output as a final answer.
- Collect
- Validate
- Review
- File and retain