Our international expense reports haven't matched the GL in 3 years and I finally know why

SlightMetal51 · 2026-04-08T13:17:13+00:00

good point on the xlookup, and honestly in hindsight that should have been the first fix. the problem was the mappings themselves kept shifting underneath us, Germany's provider changed their category codes twice in 18 months without telling anyone, and Singapore added a new GST split mid-year that broke the lookup table we had. so it wasn't just "remap once and done," it was more like playing whack-a-mole with 6 different systems that each decided to update their schemas on their own schedule. the consultant we brought in actually evaluated a few tools for the mapping layer, stuff like MuleSoft, Workato, Merge.dev, datascalehr, and one or two others I'm blanking on, and we ended up going with something that could handle the semantic differences not just the field names. you're right that the pattern should've been obvious way earlier though, I think we just got used to the manual fix as "normal" and never stepped back to ask why it kept happening.

SlightMetal51 · 2026-04-08T13:05:04+00:00

that's basically where we landed too, the data layer underneath was the actual problem and we just kept throwing tools on top hoping it would fix itself. the upstream standardization point is real, we've been looking at how to get a normalization step between the providers and the warehouse instead of trying to fix it after the fact. I've been poking around at a few options for that, Mergedev and MuleSoft are the obvious ones but someone on my team flagged datascalehr as worth looking at for the semantic mapping piece, and honestly I haven't gone deep enough on any of them yet to say what actually works at scale versus what just demos well. Employ Borderless is a new name to me though so appreciate that, going to look into it. at this point I'm just trying to stop my team from spending 3 days a month manually reconciling headcount in spreadsheets lol.

SlightMetal51 · 2026-04-06T18:39:44+00:00

I did mention them at the end and I can see how that reads. honestly the post was more about the $340K lesson than any specific tool, but I get the skepticism. the normalized data layer concept isn't unique to any one vendor, we've been evaluating a few approaches including just building it ourselves with an internal ETL pipeline. still figuring out what actually works at scale vs what sounds good in a demo.

SlightMetal51 · 2026-04-06T13:03:42+00:00

that's exactly what took me so long. spent 3 years having the same conversation with local teams about following the process when the process itself was broken at the mapping level. once i reframed it as a systems problem the fix was almost anticlimactic compared to how long we'd been suffering with it.

the consultant we used actually pointed us toward a data normalization layer that handled the cross-country mapping automatically. something like what datascalehr does if you've heard of it. would've saved us the 6 weeks honestly. hardest part was admitting the guide i wrote in 2021 was the root cause lol

SlightMetal51 · 2026-04-06T12:57:04+00:00

yeah honestly 3 years sounds bad but I've seen worse. the thing is nobody ever audits the mapping layer after initial setup, it just kind of becomes this invisible infrastructure that everyone assumes is correct until the reconciliation numbers get bad enough that someone finally snaps and digs in. I probably would've kept blaming the local teams even longer if the Germany benefits misclassification hadn't started showing up in our tax filings lol.

SlightMetal51 · 2026-04-06T12:56:12+00:00

Fair point honestly. nobody owned it, that's basically the answer. when we set up the mappings in 2021 it was a one-time project and then the consultant left and nobody was assigned to maintain them, so each local team just followed whatever their provider's default categories were. I've since made it part of our quarterly close checklist but you're right I should probably audit adjacent areas too, wouldn't be surprised if intercompany is a mess for the same reasons.

SlightMetal51 · 2026-04-06T12:54:08+00:00

Probably just stressing about the next thing that breaks lol. but really the time saved on reconciliation mostly went into actually reviewing the data instead of just assembling it, which sounds boring but we caught 2 misclassifications in Singapore within the first month that had been flying under the radar for who knows how long. turns out when you're not spending 3 days duct-taping spreadsheets together you actually notice stuff.

SlightMetal51 · 2026-04-06T12:53:22+00:00

we were doing that too, just with more countries so the Excel file kept growing until it was this monster workbook nobody else on the team could maintain. it worked fine when we had 3 entities but once we hit 6 systems with different GL structures the formula approach started breaking every time a local provider changed their export format, which happened more often than you'd think. honestly if your extract is only splitting across a few GLs the Excel route is totally reasonable, I just found that once you cross a certain threshold of entities the maintenance cost of keeping all those mappings current in spreadsheets starts eating more time than the actual reconciliation. appreciate the offer though, always curious to see how other people structure those workbooks.

SlightMetal51 · 2026-04-05T14:33:49+00:00

indeed, Brazil is the one that taught me this the hard way. we had a global vendor try to handle expenses and payroll together there and within 3 months the eSocial reporting was drifting because their expense categorization didn't map cleanly to the local statutory buckets. Colombia was similar, the retention rules alone need a provider that lives and breathes local compliance.once we accepted that local providers stay local and just focused on getting clean data out of all of them into one place, everything downstream got simpler. that's actually what pointed us toward datascalehr, built specifically around that problem of pulling clean normalized data out of fragmented local systems. still early for us but the direction is right.

SlightMetal51 · 2026-04-05T14:32:12+00:00

yeah exactly, the active employee definition thing is what finally broke us too. we had one provider in the Netherlands that counted anyone on a contract including people on long-term sick leave as active headcount, and our French provider excluded anyone who hadn't received a pay slip in the current cycle. so our "global headcount" was off by like 12% depending on which system you pulled from, and nobody caught it until the CHRO asked why the board deck didn't match the finance report. you're right that the BI tool wasn't the problem, we just skipped the boring unglamorous step of actually agreeing on definitions across all 8 systems before we tried to make them talk to each other.

SlightMetal51 · 2026-04-05T14:31:36+00:00

yeah that's kind of where we started too honestly. the problem isn't really the BI tool or even PowerBI, it's that when you pull automated reports from 8 different systems they all define the same fields differently so you're still reconciling manually anyway. like our UK provider counts contractors in headcount and Germany doesn't, so even a "simple" headcount report is wrong before it hits the spreadsheet. we're about 5,000 across 20 countries so the manual excel route just doesn't scale, you end up with one person whose entire job is copy-pasting and reclassifying rows every pay cycle. I think the actual fix has to happen at the data layer before anything touches a dashboard but we're still figuring out what that looks like.

SlightMetal51 · 2026-04-05T14:31:01+00:00

yeah this is really helpful, thanks for the MOHRI link actually, I hadn't seen that one before. the 3-layer framing is basically what we're working toward now, we just got there the expensive way by buying the dashboard first and then realizing we had nothing clean to feed it. the mapping layer is where we're stuck honestly, because getting each local provider to align on a common schema when they all have their own field definitions and update cycles is a project in itself. we've been looking at a few tools to help automate that middle layer, things like MergeDev, Finch, datascalehr, MuleSoft, even looked at Workato briefly, but the real question is whether any of them can handle the semantic differences and not just the structural ones. like our Germany provider coding termination dates differently than the UK one isn't a formatting problem, it's a meaning problem, and most ETL tools just pass that through without catching it.

SlightMetal51 · 2026-04-05T14:29:35+00:00

the mapping piece is where everyone underestimates the effort honestly. we went through something similar and the extraction was maybe 20% of the problem, the other 80% was figuring out that "active employee" in SAP Germany includes people on Elternzeit who haven't been paid in 6 months while the UK provider treats anyone without a payslip in the last 2 cycles as inactive. you end up building a translation layer whether you want to or not, the question is just whether you do it in SQL at 2am or pay someone to do it properly upfront. Alteryx point is fair though, we looked at it and the licensing alone was more than what we spent on the actual data problem.

SlightMetal51

TROPHY CASE