Implementation

A baseline is only useful if it tells you the truth on day one.

Most migrations end with a clean-looking system and an unexamined history. We run the verification rules over your existing records before go-live, which means the first thing you get is an honest account of where your books stand today - gaps included.

Typical duration: Six to ten weeks
Phases: Ingestion, mapping, validation, go-live
First deliverable: A written gap report on your own history

Four phases

What happens, in what order, and what you get at the end of each.

01Weeks 1-2

Data ingestion

Masters, opening balances, open items and transaction history come across from your existing books, along with contract documents and statutory registers in whatever form they exist today. Nothing is cleaned silently - what does not tie is listed.

OutputA loaded ledger with a written list of every balance that did not reconcile on import.

What we need from you

Trial balance and ledger extracts for the current and prior year
Customer, vendor, item and employee masters with GSTIN, PAN and MSME status
Open receivables, payables, advances and inventory positions
Contracts, board minutes, statutory registers and charge documents

02Weeks 2-4

Compliance mapping

Your registrations decide your obligations. Each ledger head is mapped to its Schedule III presentation line, each registration to its return set, each approval to its authority limit, and each obligation to a named owner.

OutputA framework configuration signed off by your finance lead, auditor and company secretary.

What we need from you

Reporting basis per entity: Ind AS or AS, Division II or III
Every GSTIN, TAN, PAN, licence and sector registration held
Delegated authority limits, and who holds them
Applicable sector frameworks confirmed with your auditor

03Weeks 4-6

Validation

The verification rules are run backwards over the imported history. This is the uncomfortable phase, and it is the one that makes the baseline real: gaps that exist in your current books surface here, before go-live, while there is still time to act on them.

OutputA gap report: unmatched ITC, missing acknowledgements, approvals out of sequence, unsupported vouchers.

What we need from you

At least one prior year of transactions and their supporting documents
Filed returns and their acknowledgements for comparison against the books
Related-party transactions with their approval dates
Prior audit observations and management responses

04Weeks 6-10

Go-live

Rollout is phased by module, not switched on at once. Core operations and the ledger go first so posting is never interrupted, then the filing calendar takes over live obligations, then the legal and contract layer. The readiness baseline is set on day one and tracked from there.

OutputA live system with a dated readiness baseline and every open gap carrying an owner.

What we need from you

A cut-over date agreed against your filing calendar, not against ours
Parallel running for one period where the risk warrants it
Role and access assignment per user, per entity
Training by role rather than a single system walkthrough

How we run it

Four rules we hold to during a rollout.

These exist because each one has been tested by a client asking us to do the opposite.

The gap report is not negotiated

If the validation phase finds that a year of input credit does not match 2B, that is in the report. We have been asked to soften these before and we do not, because a baseline that flatters you is worse than no baseline.

Cut-over follows your statutory calendar

Nobody goes live in the week a quarterly return is due, and nobody migrates the day before a board meeting. The plan is built around your filing dates from the first conversation.

Training is by role, not by screen

The person passing purchase entries and the person signing the financials need different things. Sessions are built per role, with your own data in front of them.

Phased, so posting never stops

The operational layer goes first and keeps the business running. Compliance layers are added on top of live data, which is also the only way to test them honestly.

What the gap report contains

The findings that come up most often on historical data.

None of these are unusual. They are the predictable result of books maintained without continuous verification, and every one of them is easier to deal with before go-live than during an audit.

Input tax credit claimed in earlier periods that never appeared in GSTR-2B
Filed returns whose figures no longer agree with the books after later adjustments
Related-party transactions recorded before the approval that authorises them
Vouchers above the materiality threshold with no supporting document retrievable
Fixed assets in the register that cannot be located in a physical verification
Depreciation on useful lives that depart from Schedule II with no justification on record
Statutory registers that stop part-way through a prior year
Charges satisfied in fact but still open on the MCA register

What implementation configures.

Modules

The five modules

What gets switched on in each phase, and what each one verifies.

Read on

Security

How your data is held

Isolation, encryption, access control and the append-only log.

Read on

Pricing

What onboarding includes

Where guided setup ends and a dedicated implementation team begins.

Read on

Implementation

Start with the validation phase on one historical year.

Before committing to a rollout, let us run the verification rules over a year you have already closed and audited. The gap report from that exercise tells you more about whether you need this product than any demonstration will.

Talk to us Sign up

One prior year, run against the full rule set
Findings listed with the standard each one relates to
No obligation to proceed after the report