One agreed number
A written metric dictionary ends the argument about whose revenue figure is correct, because the definition and its source fields are recorded.
Data & Technology
Data Analytics & Business Intelligence
Management reporting rebuilt as a governed data model and dashboard set, drawn from your accounting system and reconciled back to the trial balance every time it refreshes.
Overview
The problem is rarely a shortage of data. It is that the number in the board pack, the number in the ledger and the number the sales director quotes are all different, and nobody can say which is right.
The management pack is built each month by one person in a spreadsheet. It takes four days. It contains manual adjustments that were correct once and have been carried forward ever since. When that person is on leave, the pack is late. Revenue in the pack is gross of returns; revenue in the ledger is net. Nobody has written down which definition is correct, so both survive.
This engagement replaces that with a governed reporting layer. Metrics are defined once and agreed in writing. Data is extracted from the accounting system on a schedule. Every reported figure reconciles back to the trial balance. The output is a dashboard set your team owns and maintains, not a report we send you.
Scope of engagement
Scope is set by the number of source systems, the number of reporting subjects and the dashboards agreed at design stage.
Additional source systems beyond those scoped are quoted separately, since each adds its own extraction and reconciliation work.
- Reporting requirement interviews with the people who will actually use the output, resolving what decision each metric is meant to support
- Metric dictionary defining every measure in words and in formula: revenue net of GST and returns, gross margin, contribution, EBITDA, DSO, DPO, inventory days, cash conversion cycle, each with its source fields and period basis
- Source assessment across the accounting system and the operational systems feeding it, testing master data consistency, coding discipline and whether the ledger is current enough to report from
- Extraction design from platforms including Tally Prime, Zoho Books, QuickBooks, NetSuite, SAP Business One and Microsoft Dynamics 365 Business Central, using the interfaces each exposes, with scheduling and failure alerting
- Dimensional data model with conformed dimensions for entity, customer, vendor, item, cost centre and calendar, so that figures aggregate consistently across every view
- Transformation logic written and documented, including mapping of the chart of accounts to reporting groups and to Schedule III groupings
- Reconciliation control comparing the model back to the trial balance at each refresh, with a variance report produced automatically rather than on request
- Dashboard build across the agreed subjects: profit and loss against budget with variance drivers, working capital and cash, receivables ageing and collection forecast, payables and payment run exposure, customer and product profitability, and the sector-specific views your business needs
- Row-level security and access design so that a plant head, a regional manager and the board each see the appropriate cut
- Refresh runbook covering schedule, ownership, failure handling and escalation
- Handover training for the people who will maintain the model, plus written documentation of every transformation
Deliverables
- Metric dictionary, signed off before any dashboard is built
- Source assessment report with a data quality finding for each system
- Data model documentation showing tables, keys, grain and relationships
- Transformation logic in readable, documented form rather than embedded and undocumented
- Dashboard set across the agreed reporting subjects
- Trial balance reconciliation control sheet, produced at every refresh
- Access and row-level security matrix
- Refresh runbook with owners and failure procedures
- Training sessions and a recorded walkthrough of the model
- Handover pack containing every file, query and document needed to run and change the model without us
Process
-
Requirement and metric definition
We interview the users, list every metric currently in circulation, and resolve the conflicting definitions. The metric dictionary is agreed in writing before anything is built. This stage prevents most of the rework that follows a dashboard project.
-
Source assessment
Each source system is tested for extraction feasibility and data quality. If a metric cannot be produced reliably from the data that exists, we say so now and it comes out of scope rather than being approximated.
-
Model build
Extraction, transformation and the dimensional model are built and documented. The trial balance reconciliation control is built at the same time as the model, not added afterwards.
-
Dashboard build and validation
Dashboards are built against the agreed design and validated over a full reporting period alongside your existing pack. Every difference is investigated and either corrected or explained in writing.
-
Handover
Training, documentation and the refresh runbook are handed to the named owner on your side. The old spreadsheet pack is retired only once the new output has reconciled for a full period.
Benefits
Reporting that reconciles
A trial balance check at every refresh means a divergence between the dashboard and the ledger is caught by the process, not in a meeting.
Close time returned
Days spent rebuilding a pack by hand each month go back to the finance team, and the pack no longer depends on one person being available.
Nothing locked to us
Documented logic and an open handover mean your team can change a report without commissioning work from anyone.
Industries served
Technology and SaaS brings recurring revenue, cohort retention, deferred revenue movement and revenue per account. Manufacturing brings plant and stock-keeping unit margin, capacity utilisation, scrap and job costing against standard. Retail and e-commerce brings channel profitability after commission and returns, basket economics and marketplace settlement analysis. Financial services brings portfolio ageing, yield and exposure concentration. Healthcare brings payer mix, procedure profitability and collection cycle by payer.
Typical timeline
- Requirement interviews and metric dictionary: 2 weeks
- Source assessment and data quality findings: 1 to 2 weeks
- Extraction, model build and reconciliation control: 2 to 4 weeks
- Dashboard build: 2 to 3 weeks, overlapping the model build
- Validation over one full reporting period: 1 month-end cycle
- Training and handover: 1 week
Engagement model
Contracted as a fixed-scope project against the metric dictionary and dashboard list agreed at design stage, invoiced against phase completion. Changes to that list after sign-off are quoted as a variation rather than absorbed, which keeps the scope honest in both directions.
Delivery is virtual. We work from read access to your systems and a shared workspace, and we do not require write access to any accounting system. Where you want the model maintained after handover, that is a separate monthly retainer with thirty days notice.
What is not included
- Software licences and cloud subscriptions for reporting tools, databases or hosting. These are purchased by you directly.
- Data warehouse hosting, infrastructure management and database administration.
- Remediation of the underlying accounting data. If the ledger is unreconciled or the master data is inconsistent, we report it and scope the fix separately. We will not build a dashboard on top of it and call it reporting.
- Machine learning, predictive modelling and any claim of forecast accuracy. We build driver-based forecasts from observable drivers and describe them as such.
- Real-time or streaming data pipelines. Refresh schedules are periodic and stated.
- Integration development between operational systems, which sits with your implementation partner.
- Non-finance analytics such as marketing attribution, web analytics and product telemetry.
- Statutory reporting output. Dashboards are management information and are not a substitute for financial statements, GST returns or any statutory filing.
- Information security certification or assurance over your data environment. Tax-Samadhan holds no security certification and makes no such claim.
- Ongoing dashboard maintenance and user support after handover, unless separately retained.
Any figure in a dashboard is management information. It carries no assurance and should not be relied on as an audited number.
Frequently asked questions
Yes, and it is the first thing we address. The usual causes are a different revenue definition, a different period cut-off, and manual adjustments applied in the spreadsheet that never reached the ledger. We build a reconciliation control that ties every reported figure back to the trial balance at each refresh, so a divergence is caught by the system rather than by someone in a board meeting.
Power BI, Looker Studio, Metabase and Excel with Power Query are all workable, and the choice follows your existing licences and your team's skills rather than our preference. We hold no partner or reseller relationship with any tool vendor and take no commission. For many companies of this size, a well-built Power Query model is a better answer than a new licence.
Yes. Tally Prime exposes data through its ODBC connection and its XML request interface, and both work for scheduled extraction of ledgers, vouchers and masters. Zoho Books, QuickBooks Online, NetSuite and SAP Business One all expose APIs or database access. Where an extraction path is limited, we say so at the assessment stage rather than after the model is built.
Then we tell you before building anything. A dashboard on unreliable data is worse than no dashboard, because it lends false authority to a wrong number. The assessment tests master data consistency, coding discipline and reconciliation status. Where the data will not support a metric, that metric is excluded and the remediation is scoped separately.
We build driver-based forecasting where the drivers are real and observable, such as a receipts forecast derived from debtor ageing and collection behaviour. We do not sell machine learning or predictive analytics on the transaction volumes a company of this size produces. There is usually not enough data for a model to beat a well-constructed driver, and we will say so.
You do, and the handover is designed for it. You receive the data model documentation, the transformation logic in readable form, the refresh runbook and two training sessions with the people who will own it. Nothing is locked in a proprietary format we control. Where you would rather we maintained it, that continues as a small monthly retainer.
Daily for operational views such as receivables ageing and cash position, and after close for anything that must reconcile to the ledger. Refreshing a management profit figure daily against an open ledger produces numbers that change for no reason a manager can explain, which is the fastest way to lose trust in a reporting system.
Related services
- Digital Transformation Consulting where the reporting problem turns out to be a system and process problem underneath.
- Virtual CFO Services where the reporting layer needs a senior owner to interpret it and act on it monthly.
- Investment Research where the analysis needs to extend beyond your own data to markets and comparable companies.