Counterparty onboarding and master data: the real critical path

Ask a team why a mandate project slipped and you will rarely hear "the format mapping took too long". You will hear that half the customer records had no tax ID, that nobody knew which counterparties could actually receive, or that an accreditation took three months nobody had budgeted. The invoice format is the part engineering controls. Master data and onboarding are the parts it does not — and they are almost always the real critical path.

1. Why master data is the long pole

Technical build effort is largely under your control: you can add people, parallelise, and the work shrinks. Master data and onboarding are different — they depend on the state of records you did not create and on third parties who move at their own pace. You cannot engineer your way out of a customer whose VAT number is wrong, or a tax authority whose accreditation queue is eight weeks deep.

That asymmetry is why these items dominate the schedule. They are not hard in the sense of being intellectually difficult; they are hard because they are slow and external, and slow-and-external does not respond to effort the way code does.

2. How parties are identified

Every regime has to answer "who is this party?" and the identifier scheme it chooses decides how much master-data work you have signed up for. The common schemes:

• VAT number — familiar, but format and validity vary by country, and a syntactically valid number can still be deregistered or wrong.
• National tax or company identifier — a domestic code that may or may not map cleanly to what you hold.
• A scheme-qualified network identifier — on Peppol, a participant is identified by a scheme plus a value (an electronic address), where the scheme is drawn from a controlled code list. The same company can be addressable under more than one identifier.
• A platform-issued code — some clearance regimes assign their own taxpayer identifier you must capture and use.

The trap is assuming you already hold the right identifier in the right form. You usually hold an identifier — a name, an internal customer number, maybe a VAT number of uncertain vintage — and the mandate wants a specific, validated, scheme-qualified one. Closing that gap across a whole customer or supplier base is the work.

3. Can they even receive?

The second question — can this counterparty accept a structured invoice, and how do I find out? — splits sharply by model.

• On a network like Peppol, capability is discoverable: the Service Metadata Locator points you to the counterparty's Service Metadata Publisher, which declares what document types that participant can receive. You can look before you send, and route automatically. The onboarding cost is real but bounded.
• In a portal or bilateral regime, there is often no lookup at all. You find out whether a counterparty can receive by asking them, one at a time. That makes onboarding a manual, per-relationship project — exactly the kind of work that does not compress and has to be staffed.

Knowing which world each in-scope country puts you in is the difference between an automated routing feature and a call-centre-sized onboarding effort.

4. The lead times you cannot compress

Two external clocks routinely blindside roadmaps:

• Taxpayer registration / enrolment. Registering on an authority's portal, obtaining certificates or keys, or being assigned a platform identifier can take weeks and cannot be rushed with engineering.
• Service-provider accreditation. Where a regime requires an accredited provider (many five-corner and clearance regimes do), accreditation carries its own lead time — often conditioned on things like passing conformance test suites, holding a local presence, or a minimum operating history. If you or your provider are not already accredited when the project starts, that timeline may be longer than your entire build.

Engineering compresses; accreditation queues and certificate issuance do not. Put the external clocks on the critical path on day one, because they will be there whether you plan for them or not.

5. Master-data quality, concretely

"Improve master data" is too vague to action. The concrete work, per counterparty, is usually some combination of:

• Presence — is the required identifier there at all?
• Validity — does it pass the scheme's format and check-digit rules, and is it currently registered?
• Correct scheme — is it the identifier type the mandate expects, not merely an identifier?
• Addressability — for network regimes, does the counterparty actually resolve to a receiving endpoint?
• Deduplication and mapping — do your internal records map cleanly to one real-world, identified entity?

Each of these is a column you can measure and a backlog you can burn down — which is exactly why it should be started early and tracked, not discovered in user acceptance testing.

6. Planning around it

Three moves keep master data from becoming the reason you miss the date:

1. Profile the data before you design the build. Run the presence/validity/scheme/addressability checks across the population on day one; the gap you find sizes the real project.
2. Start the external clocks immediately. Registration and accreditation are the first tasks, not the last — begin them before a line of mapping code is written.
3. Staff onboarding as its own workstream where the regime has no lookup. It is operational work with its own owner, not a subtask of the integration.

This is the practical face of the point we keep returning to in reading a new country mandate: the technical build is rarely the critical path. Accreditation lead times and counterparty master data usually are — and the teams that hit their dates are the ones that treated those as the schedule's spine from the start.