Payroll versus vendor reconciliation, and the gross-up problem
Every mobility cost exists in at least two systems, and usually disagrees between them. The estimate said one number, home payroll paid another, the vendor invoiced a third, and the tax gross-up that reconciles them all will not settle until after year-end. For finance teams, this is the page that matters most, because reconciliation is where mobility data stops being an HR reporting question and becomes a controls question. It is also, not coincidentally, the first capability Ask & Chart shipped for the mobility pack.
The gross-up, and why it is the hardest line
A tax gross-up is the employer-paid tax on a benefit, calculated so the assignee is kept whole: pay someone's rent in a country that taxes housing benefits and you owe the tax on the benefit, and the tax on that tax. Under the balance sheet approach that roughly 85% of multinationals still use, gross-ups sit on top of cost-of-living allowances, housing differentials and education support, spanning the home and host tax systems and often a shadow payroll that exists only for tax reporting. Two verified facts locate the difficulty. In ECA's package benchmarks, benefits plus tax frequently cost more than the assignee's cash salary itself: the hardest-to-calculate half of the package is the bigger half. And the industry only productized the calculation at scale in February 2026, when Ineo extended integrated global gross-up across 100+ countries: evidence of demand, and of how late the tooling is.
The measured cost of unreconciled feeds
The consequences are quantified by the industry's own surveys. EY 2026: only 51% of employers say their mobility data is accurate, which is the direct price of feeds that never meet. KPMG 2025: payroll reconciliations rank alongside cost projections as the top calculation targets for AI investment, named by 47% of organizations, and lack of data integrity is a top-three analytics obstacle at 43%. Behind the percentages sits a plain operational fact: an unreconciled program cannot answer whether it overpaid a vendor, double-funded an allowance through both payroll and an invoice, or under-accrued the year's gross-up liability. Each of those is a real money question, not a reporting nicety.
Why reconciliation fails in spreadsheets
Reconciliation is a join problem before it is an arithmetic problem. To compare payroll actuals against vendor invoices and against the estimate, each record must resolve to the same assignee, assignment, period and cost component, across systems that share no keys: payroll knows an employee ID, the RMC a file number, the tax firm a case reference, and the estimate a candidate name typed slightly differently. Spreadsheet reconciliation dies on exactly this: fuzzy matches done by eye, once a year, unverifiable afterwards. The arithmetic that follows the join is trivial; the join is the work. This is why Ask & Chart's key magnet treats matching as a first-class, human-confirmed step: candidates proposed with evidence and confidence, fan-out and double-count risks flagged, every confirmation recorded. Confirm the joins once, and the comparisons become deterministic queries that run weekly instead of an annual archaeology project.
The discrepancy scorecard
On confirmed joins, Ask & Chart's discrepancy scorecard (shipped today) runs deterministic checks across the feeds: estimate versus actual by component, payroll versus invoice by period, allowance funded twice, gross-up accrual versus methodology. Each finding shows the rule version that produced it, the source records behind it, and a severity, and each carries an audit-trail entry from detection to resolution. Two design decisions matter for finance buyers. Findings are evidence for a human, never an automated verdict: the scorecard says these two records disagree by this amount for this apparent reason, and a person decides. And the checks are versioned, so when a number is challenged months later, the exact rule and data that produced the finding are reproducible. For a program preparing for pay transparency reporting duties, the same spine (deterministic checks, provenance, audit trail) is what makes per-assignee compensation data defensible, not just tidy.
From annual cleanup to weekly routine
The end state is unglamorous and valuable: reconciliation as a weekly routine rather than a year-end project. New feeds land, schema drift is detected (a vendor changed its export: dependent figures pause instead of silently corrupting), findings queue for review, and the program dashboard's variance-to-budget figure is one you can defend line by line. That is the wedge Ask & Chart leads with in mobility, because it is the use case where trust is earned fastest: the first working session takes one corridor's payroll, invoices and estimate, and shows you the disagreements you did not know you had.
Frequently asked questions
What is a tax gross-up and why is it error-prone?
The employer-paid tax on a benefit so the assignee is kept whole. It spans home and host tax systems and shadow payroll, and integrated multi-country calculation tooling only reached broad coverage in 2026.
What should a mobility reconciliation actually compare?
Estimate versus actuals by cost component, home and host payroll versus vendor invoices by period, and accrued versus settled gross-up, all resolved to the same assignee and assignment through confirmed record matches.
Can this run on the data we already have?
Yes; that is the design constraint. Payroll extracts, vendor invoices and estimate files in whatever format they arrive. The system proposes the record matches, you confirm them, and the checks run from then on.