A decision you can defend
A scored evaluation against a written requirement gives the board a record of why a platform was chosen, which matters most when something later goes wrong.
Data & Technology
Digital Transformation Consulting
Vendor-neutral assessment, selection and migration planning for finance systems, covering current process design, chart of accounts, data migration, statutory reporting readiness, user acceptance testing and a reconciled cutover.
Overview
Most finance system projects fail before any software is chosen. They fail because nobody wrote down what the system has to do.
The starting position is usually a working accounting package surrounded by spreadsheets. The ledger holds the transactions; the spreadsheets hold the reporting, the pricing, the reconciliations and the cash forecast. Someone rebuilds the management pack every month by hand. Purchase orders are raised outside the system, so nothing matches. The chart of accounts has grown by accretion and no longer supports any reporting cut anyone actually wants. Then a demo is seen, a decision is taken quickly, and the same problems are migrated into a more expensive system.
This engagement takes the step that is normally skipped. We document the current process, define what the future one must produce, and only then test platforms against it. Selection is vendor neutral. Migration is planned, tested and reconciled rather than attempted over a weekend.
Scope of engagement
Scope is agreed in phases, and you can stop after the assessment if the finding is that a system change is not warranted.
Where you already have a preferred platform, the selection phase is replaced by a fit-gap assessment against your requirements.
- Current-state process mapping across order to cash, procure to pay, record to report, inventory movement and payroll interface, documented as it is actually run rather than as the manual describes it
- System landscape inventory: every application, spreadsheet and manual handoff in the finance path, with the data that moves between them and who moves it
- Pain point register with the cost of each item expressed in effort, delay or error rate
- Chart of accounts and cost centre redesign, structured so that Schedule III presentation, GST reporting and management reporting all draw from the same coding without manual mapping
- Master data design for customers, vendors, items, tax codes and units of measure, with ownership and change control defined
- Requirement specification written as testable statements, separated into mandatory, important and optional
- Statutory output requirements: GSTR-1 and GSTR-3B data, e-invoice generation and IRN handling where the turnover threshold applies, e-way bill data, TDS section mapping and Form 26Q data, and Schedule III grouping
- Audit trail requirement testing, covering whether the candidate system maintains an edit log, whether it can be disabled, and how long it is retained
- Access control and segregation of duties design, including maker and checker roles and the approval matrix the system must enforce
- Vendor-neutral platform evaluation with a published scoring model, scripted demonstrations against your own scenarios, and total cost assessed over three years including licence, implementation, integration and internal effort
- Migration plan covering masters, opening balances, open items, fixed asset register and historical data retention under the eight-year statutory record requirement
- Cutover plan with a dated task list, a reconciliation gate at each step, a parallel run window and defined rollback criteria
- User acceptance test scripts written from the requirement specification, with expected results stated before testing begins
- Post go-live stabilisation through the first close in the new system
Deliverables
- Current-state process documentation with the system landscape diagram
- Pain point register with quantified impact
- Future-state process design and the chart of accounts and master data specification
- Requirement specification suitable for issue to implementation partners
- Evaluation scoring model, scripted demonstration scenarios and a written selection recommendation with the reasoning shown
- Three-year total cost comparison across shortlisted options
- Migration plan with the data mapping sheet and the opening balance reconciliation template
- Cutover runbook with dated tasks, owners, reconciliation gates and rollback criteria
- User acceptance test scripts and the results log
- Access control matrix and segregation of duties map
- Go-live readiness assessment and, at the end, a handover pack with the documentation set
Process
-
Assessment
Process interviews, system walkthroughs and a data review establish how finance actually runs today. The output states plainly whether your problem is a system problem, a process problem or both. Two to three weeks.
-
Design and specification
Future-state processes, the chart of accounts, master data and controls are designed and signed off. The requirement specification is written from that design, not from a vendor’s feature list.
-
Selection
Shortlisting, scripted demonstrations against your own scenarios, reference checking, and a three-year cost comparison. The recommendation is written with its reasoning exposed so your board can test it.
-
Migration and cutover
Data mapping, trial migration, reconciliation of opening balances and open items, user acceptance testing, then cutover to the runbook with a parallel run over one full month-end cycle.
-
Stabilisation and handover
We work through the first close in the new system, confirm that statutory outputs reconcile, close open defects with the implementation partner, and hand over the documentation set.
Benefits
Opening balances that tie
Reconciling the trial balance and open item listing in both systems before cutover prevents the difference that otherwise sits in suspense for a year.
One coding structure
A chart of accounts designed for statutory, tax and management reporting at once removes the monthly mapping spreadsheet between them.
No commission in the advice
We take no fee, margin or referral payment from any software vendor, so the recommendation carries nothing beyond the requirement list.
Industries served
Manufacturing brings bill of materials, job work movement, costing and warehouse integration. Retail and e-commerce brings channel and marketplace integration, returns handling and high transaction volume. Technology and SaaS brings subscription billing, revenue schedules and multi-currency receipts. Healthcare brings clinical and hospital information systems feeding the finance ledger, and payer billing structures. Growth-stage companies bring a first move off spreadsheets, usually under investor reporting pressure and on a fixed budget.
Typical timeline
- Assessment: 2 to 3 weeks
- Design and requirement specification: 3 to 4 weeks
- Selection, including scripted demonstrations and reference checks: 3 to 4 weeks
- Migration preparation, trial migration and user acceptance testing: 4 to 6 weeks, in parallel with partner build
- Cutover and parallel run: one full month-end cycle
- Stabilisation through first close and handover: 4 to 6 weeks
Engagement model
Contracted phase by phase against a written deliverable list, with a decision point at the end of each phase. You are free to stop after assessment, after design, or after selection, and several clients do. Fees are fixed per phase rather than time-based, so the estimate you approve is the amount invoiced.
Delivery is virtual, through scheduled working sessions, a shared documentation workspace and read access to your current systems. Where an on-site session is genuinely needed for a warehouse or plant process walkthrough, it is agreed and quoted separately in advance.
What is not included
- Software licences and subscriptions. These are purchased by you directly from the vendor. We do not resell them and do not take a margin.
- Implementation and configuration of the chosen platform, which is performed by the implementation partner you appoint.
- Custom software development, report writing inside the platform, and integration coding.
- Infrastructure, hosting, networking, hardware, barcode and weighbridge equipment.
- Ongoing helpdesk, user support and system administration after handover.
- Clearing a bookkeeping backlog so that data is fit to migrate. If the ledger is not current, that work is scoped separately and must be finished before cutover.
- Data entry of historical transactions into the new system beyond the agreed migration scope.
- Information security certification, penetration testing and vulnerability assessment. Tax-Samadhan holds no security certification and makes no such claim.
- End-user training as a standing programme. We train the finance team on the processes we designed; platform training is provided by your implementation partner.
- Contract negotiation and legal review of the vendor agreement.
If the assessment concludes that your existing system is adequate, that is the finding we deliver. We do not have a system to sell you.
Frequently asked questions
No. Tax-Samadhan holds no partner, reseller, referral or alliance relationship with any software vendor and receives no commission, margin or fee from one. We describe compatibility with the platforms our clients use, and nothing more. If we recommend a system, the only thing behind that recommendation is the requirement list you signed off.
In practice, Tally Prime, Zoho Books, QuickBooks, NetSuite, SAP Business One, Microsoft Dynamics 365 Business Central and Odoo, along with the payroll, billing and warehouse tools that sit around them. Working with a platform means we understand its data model, its statutory reporting behaviour and its limits well enough to test it against your requirements. It does not imply any commercial relationship.
Implementation configuration, custom development and technical support are done by the implementation partner you appoint. We write the requirement specification, run the selection, design the process and data model, and hold the partner to the specification during build and testing. Keeping specification separate from build is deliberate: the party writing the requirement should not be the party marking its own work.
Often you should not. A large share of the pain attributed to Tally is process pain that would follow you to any new system: no purchase order discipline, an unusable chart of accounts, and reporting assembled in spreadsheets. Our assessment says so when that is the finding, and a process-only engagement is a legitimate and much cheaper outcome.
Opening balances. Masters migrate acceptably; open items rarely do. Partly settled invoices, advances, credit notes, retention balances and unreconciled bank items are the ones that do not carry across cleanly. We reconcile the opening trial balance and the open item listing in both systems line by line before cutover, and treat any unexplained difference as a blocker rather than an adjustment.
A parallel run of one full month-end cycle is the usual answer, sometimes two where statutory returns fall inside the window. It is deliberately short, because a long parallel run doubles the workload and people quietly stop maintaining the old system, which destroys the comparison the parallel run exists to provide.
A stabilisation period of four to six weeks in which we sit with your team through the first close in the new system, resolve reporting differences, and confirm that the statutory outputs reconcile. After that the engagement ends with a documented handover. We do not stay on as a permanent helpdesk.
Related services
- Data Analytics & Business Intelligence for the reporting layer once the transaction data sits in one place.
- Data Reconciliation Services for opening balance and post-migration reconciliation carried out as a separate exercise.
- Virtual CFO Services where the finance function needs an owner to run the new processes after go-live.