← Back to global tracker

Education

Preparing for a Mandate

Once you understand the mandate model and its likely impact, the practical questions become: who should be in the room, how early should this start, and how do you approach choosing a vendor without regretting it a year later?

Last updated: 25 July 2026
12–18 mo
Recommended lead time before go-live
6–8
Typical core working group size
4 phases
Of a well-run vendor selection
01

Who to include

A mandate response with no single accountable owner, or with the wrong functions missing from the room, is the most common cause of late surprises. Here's a working group that covers the ground without becoming unwieldy.

Programme sponsor

A senior Finance or Tax leader with the authority to commit budget and resolve cross-functional disagreements. Without this, the working group can identify problems but not always act on them quickly.

Tax / compliance lead

Owns the interpretation of the actual legal requirement, tracks scope and deadlines across entities, and is usually the one relationship-managing any external advisors.

IT / integration lead

Assesses what the current ERP/AP/AR systems can and can't do natively, and owns the technical relationship with whichever vendor or platform gets selected.

Legal & data protection

Reviews vendor contracts, data residency implications, and cross-border transfer questions — brought in from the start rather than at contract-signing, when it's too late to influence the shape of the deal.

Business/entity owner(s)

Someone accountable for each affected country or business unit — particularly important in multinationals, where the same mandate can land differently depending on local entity structure and existing systems.

Procurement / vendor management

Runs the formal RFP process if one is needed, and ensures contract terms (SLAs, exit clauses, liability) get proper commercial scrutiny rather than being accepted as vendor boilerplate.

Keep this group to 6–8 people who meet regularly, with a wider circle (AP/AR team leads, key customers or vendors for testing, external advisors) consulted at specific milestones rather than in every meeting.

02

When to start

Grace periods and phased thresholds are common, and it's tempting to treat them as the real deadline. In practice, vendor lead times, testing cycles, and cross-functional coordination all take longer than expected — starting early is what actually determines whether go-live is calm or chaotic.

12–18 months before go-live
Assessment & scopingStart here
Confirm scope, form the working group, assess current systems

Determine which entities are actually in scope and from when, form the core working group above, and get an honest read on what your current ERP/AP/AR systems can and can't do without help.

9–12 months before go-live
Vendor selection & solution design
Run the vendor selection process (see below) and confirm the technical approach

This is usually the single most time-consuming phase — treat it as its own project with its own timeline, not a quick procurement exercise.

6–9 months before go-live
Build & integration
Technical integration, master data cleansing, internal process design

Master data cleansing in particular benefits from a long runway — it's rarely a quick fix once you actually look at the state of customer/vendor records.

3–6 months before go-live
Testing & pilot
Sandbox/certification testing, then a live pilot with a small transaction subset

Deliberately test failure paths — rejections, corrections, offline/contingency modes — not just the happy path where everything validates first time.

1–3 months before go-live
Parallel run & cutover prep
Run old and new processes in parallel, train frontline staff, finalise contingency plans

This is also when to brief customers and key vendors on what's changing, if the mandate affects how they'll receive or send invoices to you.

Go-live and beyond
Stabilisation
Monitor rejection rates closely for the first few weeks

Rejection rates typically spike immediately after go-live as real-world data edge cases surface that testing didn't catch — budget attention for this rather than assuming go-live is the finish line.

03

Planning a vendor selection process

Whether you need a full-service compliance platform, a specific country intermediary (a PAC, OSE, or Access Point), or just a module within your existing ERP, the same disciplined process pays off.

Define requirements before talking to any vendor

Country/format coverage needed, expected transaction volume, required integration method (API vs. portal), and budget range. Going to market without this tends to produce proposals that are hard to compare fairly.

Map the realistic vendor landscape

Options usually span full-service global compliance platforms, country-specific intermediaries, and native ERP add-on modules — each with different trade-offs on coverage breadth versus depth and cost.

Score on more than price

Format/country coverage, uptime and support SLAs (including support hours relative to your time zone), security certifications, integration effort required on your side, and — critically — their track record of keeping pace with regulatory changes in the countries you need.

Insist on a proof of concept

A sandbox test with your own real (or realistic) data surfaces integration friction that a sales demo never will. Treat this as non-negotiable before signing, not an optional nice-to-have.

Scrutinise the contract, not just the product

Data residency commitments, liability for errors or missed deadlines, minimum continuity periods if you switch providers, and clear exit/data-portability terms — get Legal and Procurement involved in this stage directly, not as a final rubber stamp.

Plan for the next mandate, not just this one

If you operate in multiple markets, ask how the vendor's roadmap covers countries you don't need yet but might soon — switching providers again in two years is a real cost worth avoiding if a single relationship can reasonably grow with you.

04

Common pitfalls

Patterns worth watching for, based on how these programmes typically go wrong.

⏳ Treating the grace period as the real deadline

Enforcement holidays exist to ease the transition, not to signal there's no urgency — the underlying technical and process work still needs to happen on the original timeline.

🗂️ Skipping master data cleansing

The single most common cause of early rejections, and the easiest thing to deprioritise under time pressure — it rarely pays off to skip it.

🙋 No single accountable owner

When Finance, IT, and Legal each think someone else is driving, gaps surface late — usually right when there's no time left to fix them.

🧪 Only testing the happy path

Rejections, corrections, and contingency/offline modes are exactly where real operational pain shows up — test these deliberately, not just the case where everything works first time.

🌍 Assuming one market's solution transfers to the next

A vendor or approach that works well in one country's model doesn't automatically fit another's — re-verify fit market by market rather than assuming.

💸 Comparing vendors on pilot-volume pricing

Cost structures that look similar at low volume can diverge sharply at real production volume — always model pricing at your actual expected scale.

05

Quick-start checklist

  • Named programme sponsor with budget authority, confirmed
  • Core working group formed — Tax, IT, Legal, Procurement, and affected business units represented
  • Scope confirmed: which entities, from when, under which compliance model
  • Current system capability assessed honestly, gaps documented
  • Vendor requirements documented before any vendor conversations begin
  • Proof-of-concept testing scheduled before contract sign-off, not after
  • Master data cleansing plan in motion, not deferred to "later"
  • Rejection and correction workflows explicitly tested, not assumed
  • Frontline (AP/AR, sales order entry) training scheduled ahead of go-live
06

Where to go next