Testing a new return before the first submission

First submissions fail for reasons that have nothing to do with the numbers. They fail because nobody could log in, because the certificate was issued to the wrong entity, because the test environment needed an enrolment of its own, or because the authority’s own validation layer rejected something no published rule mentions. The build is the visible half of a first filing; the plumbing is the half that determines the date.

1. Enrolment first, and earlier than feels necessary

Across every market in this cluster, channel enrolment is the longest single lead time in a first submission, and it is frequently granted per process rather than once per firm. Completing one enrolment does not entitle you to file a different return.

Several markets attach express deadlines to enrolment itself, independent of any filing. Where they do, the enrolment is a compliance obligation in its own right and a late enrolment is a breach even if no return was yet due.

2. The test sequence

3. The parallel run is the only stage that tests meaning

Stages 2 to 4 test whether the file is acceptable. None of them tests whether it is right. A return can pass every published validation rule and every national check while stating something that is not true, because validation rules test internal consistency and plausibility, not correspondence with reality.

The parallel run is what closes that gap. Build the return for a period you already understand, then reconcile it — to the ledger first, and to any other return covering the same population second. Differences should be attributable before the first live filing, not after the first supervisory question.

Where the return replaces an existing one, run both for at least one period and bridge them. Where it is genuinely new, the ledger reconciliation is the only anchor available, which makes it non-optional rather than a nice-to-have.

4. The dry run nobody schedules

The last rehearsal worth doing is the one that tests the process rather than the file: produce and submit the return end to end, at the pace and with the people who will do it in production, on the calendar days it will actually happen.

That surfaces a specific class of problem the technical tests cannot:

• the extract depends on a month-end close that lands after the internal deadline;
• the only person who can approve is on the approval path for three other returns in the same week;
• the submission window is shorter than assumed, or does not run at the hours assumed;
• the acknowledgement is asynchronous and nobody owns checking for it.

That last one is the most common quiet failure of all. A submission is not complete when the file is sent; it is complete when the acknowledgement is received and recorded. A process with no owner for the acknowledgement will eventually record a rejected file as filed.

5. A worked sequence

Facts: a firm identifies a new return with a first reference date one quarter away and a remittance date six weeks after that.

What a workable plan looks like: enrolment starts immediately and in parallel with everything else, because it is the only item whose duration the firm does not control. The mapping is built against the specification applicable to that reference date. A prior period is built and reconciled as a parallel run before the reference date arrives. A test submission goes in as soon as the channel allows. The live build then has the remittance window to itself, rather than sharing it with a first attempt at logging in.

What the practitioner records: the enrolment evidence, the specification version, the parallel-run bridge, the test-submission result and the acknowledgement — because that set is also exactly what a supervisor asks for if the first live filing goes wrong.

FAQ

Related: Building a reporting pipeline · Reconciling returns · Validation rules