A batch of invoices came in for reconciliation during a client's move from Coupa to Ariba, and thousands of them had no match anywhere in the new system. Not late. Not wrong. Just absent, as if they'd been sent into a system that had never heard of them. I don't know what actually happened on the client's side during that migration — I wasn't in the room for it, and I'm not going to pretend otherwise. What I have is a hypothesis, and I want to be honest that it's a hypothesis and not a fact I'm dressing up as one: a gap that size, made of invoices that don't match rather than invoices that are late or malformed, is close to a fingerprint for one specific failure. Somebody didn't get told the address changed.
That distinction matters more than it sounds like it should. I've written before about the failure mode where someone gives a confident, ungrounded answer to a question nobody actually checked, and it gets treated as settled fact from that point on. This is the opposite move, on purpose: an informed guess, stated as a guess, because I've seen this specific shape of gap often enough to trust the pattern without pretending I've confirmed the cause.
Here's why this particular failure shows up so often it's practically a genre. The team running a platform migration owns the migration — get the new system live, get the old one decommissioned, hit the cutover date. The team that owns the actual vendor relationships is usually a different team, with a different manager, a different set of priorities, and its own backlog that doesn't have "help the systems team" anywhere on it. Vendor communication during the cutover needs to belong to one of them, explicitly, and it very often belongs to neither — not because anyone decided it wasn't important, but because everyone assumed someone else had it. That's the same organizational shape as the SAP dependency I've written about before, except that story was about a team correctly gatekeeping something that mattered. This one is about a task nobody gatekept at all.
Nobody notices a vendor didn't get the memo the day it happens. There's no error, no failed request, nothing to page anyone about — the vendor just keeps doing exactly what they did before, because as far as they know nothing changed. The invoice shows up, addressed the old way, formatted the old way, and it sits there unmatched until someone runs a reconciliation big enough to notice the pile. By then it isn't one vendor's confusion. It's a backlog with a few thousand line items in it, and the honest starting point isn't "why did the data break" — it's "who did we forget to tell." The vendors most likely to fall through this gap are the same ones least likely to get noticed falling through it: low-volume, long-tail vendors who aren't on anyone's short list for a personal heads-up call, and whose absence doesn't look like anything until it's added up.
The fix isn't more careful project planning in the abstract. It's assigning vendor communication to one specific team, by name, before the migration starts — not as an assumed byproduct of "the vendors will figure it out" or "someone will loop them in." If the migration team and the vendor-relationship team can each point to the other as the ones handling it, that's the exact condition that produces this pattern, and it produces it quietly enough that nobody finds out until the invoices that didn't make it are sitting in a pile with a number attached that's hard to look at.
Field Mappings