The implementation project: six months broken down

You know the requirement, the data and the route. This station puts them on a schedule.

Six months is not an arbitrary number: it is the minimum notice the Saudi authority states for wave notification, as in station two. It is ample for somebody who started with their data, and tight for somebody who started with their system.

The plan, month by month

Month	What happens	Completion criterion
1	Inventory and measurement: the seven lists, and readiness across two hundred invoices	A written number, and an owner per list
2	Contract and design: the route chosen, and a field map from your system to the document	A complete field table, with no field sourced from “we’ll see”
3	Data cleaning in parallel with building the integration	Readiness above 90%
4	Testing in a sandbox: every scenario, not the happy one alone	Every scenario passed at least once
5	Parallel run: real issuance and real submission while the old way continues	Acceptance above 98% for four weeks
6	Cutover and daily monitoring	A daily rejection report, with an owner

Months one and three are the real project. The rest is execution.

The scenarios that get tested

Most projects test the easy case alone: a domestic invoice at the standard rate to a customer with complete data. Then the rest is discovered on real invoices.

The minimum list:

• A domestic sale at the standard rate.
• An export at zero rate — and the evidence it depends on.
• An exempt good or service, with the basis of exemption.
• A reverse charge on an imported service.
• A discount at invoice level rather than line level, and its effect on the base.
• A credit note amending an issued invoice.
• An invoice in a foreign currency and its exchange rate.
• An advance payment and its later settlement.
• A customer with no tax registration number — so you learn what your system does.
• A one-line document and a hundred-line document — because the limits appear at both ends.

The last two are always skipped, and they are the two that expose the system’s limits.

The parallel run — month five

This is the most important paragraph in the station.

A parallel run means issuing the new way and actually submitting, while the old way continues, at least a month before the mandate.

Why is sandbox testing not enough? Because a sandbox tests what you thought of. A parallel run tests what you did not: the customer created today with no tax number, the item the warehouse added yesterday with no code, and the employee who found a way around the mandatory field.

And the readiness criterion is one number: acceptance above 98% for four consecutive weeks. Not “development is finished”.

Anybody who did not run in parallel meets the difference on mandate day, when every error is money that is not collected.

Who sits at the table

E-invoicing projects usually fail because they are run by one person in one department.

Role	Their responsibility	Share of their time
File owner	Decisions and escalation, and from finance	30%
Customer data owner	From sales, runs the outreach campaign	20% in the early months
Item and coding owner	From purchasing or the warehouse	20%
IT or the provider	Integration and certificates	Depends on the route
Executive sponsor	Approves policy and opens closed doors	Two hours a month

The last row is the one that gets skipped and is needed at least twice: when you need the “no data, no invoice” policy, and when you need a decision to narrow scope before the deadline.

One question reveals whether the project is actually being managed: who can say “we will not meet this date” and be heard? If that person has no name, the project is heading for its deadline with no brakes.

What gets written before launch

Three documents, one page each.

One: the outage procedure. What you do when approved issuance is impossible — who decides, after how many hours, and what the fallback is. Signed off by management rather than by IT.

Two: the correction procedure. How a wrongly issued invoice is corrected, who approves the note, and within how many days.

Three: the daily monitoring procedure. Who opens the rejection report, at what hour, and to whom it escalates after how many days.

The third is the one that gets forgotten, and the one that decides whether the project collapses three months after succeeding.

What you actually do in this station

• Put the plan on a real calendar against your mandate date, and work backwards.
• Write the ten-scenario list and make it a signed-off test checklist.
• Plan the parallel run from day one, because it needs approval and resources.
• Write the three documents and have them approved before month five.
• Define the readiness criterion as a number, and put it where management sees it.

The three commonest mistakes

One: starting with integration before data. The integration finishes in month two and then waits four months for the data.

Two: testing the happy scenario. The rest is discovered on real invoices.

Three: cancelling the parallel run for lack of time. It is the first thing cut under pressure, and the most regretted cut.

The acceptance test for this station

1. Show your month-by-month plan with real dates and completion criteria.
2. Name the ten scenarios and the test status of each.
3. Explain why sandbox testing does not replace a parallel run.
4. State your readiness criterion as a number and a duration.
5. Show the three documents and who approved them.

What comes next

You have launched. The next station is about the day after, and every day after that: why invoices get rejected — the recurring causes, how to read the error, and who fixes it.