From Spreadsheets to One Source of Truth: A Practical 90-Day ERP Roadmap

Most growing businesses do not decide to run on spreadsheets. It just happens. The online shop came first, then a POS app for the counter, an accounting package for the tax filing, a payroll sheet that one person understands, and a courier portal that somebody checks every evening. Each tool was a good decision on the day it was bought.

Three years later, the same business spends the first week of every month reconciling those tools with each other. Nobody fully trusts the dashboard, because every number on it lives in at least two places. That is the moment an ERP stops being a "big company" word and becomes a practical question: how do we get to one source of truth without stopping the shop?

This article is the roadmap I give owners and operations leads when they ask that question. It is written from the architect's side of the table: what "integrated" really means, the signs you have outgrown your tools, a phased 90-day rollout, the traps that sink ERP projects, and the numbers that tell you it worked.

The real cost of disconnected tools

The licence fees for five separate tools are rarely the problem. The problem is the work that happens between them. It is invisible on any invoice, so it is easy to underestimate. Here is what it usually looks like:

• Re-keying. Orders are exported from the shop and typed (or imported) into accounting at month end. Every manual step is a chance to drop a decimal or a discount.
• Stock drift. The online store, the POS counter and the warehouse sheet each hold a different number. The store oversells, or hides products that are actually on the shelf.
• Cash you cannot see. Cash on delivery sits with the courier for days. Matching their settlement file to your orders is a manual job, and unmatched rows quietly become write-offs.
• Payroll in isolation. Attendance lives in one place, leave in another and salaries in a sheet. The payroll run never reaches the ledger as a proper journal entry.
• Reports that disagree. Sales in the shop dashboard never match revenue in the accounting software, so every meeting starts with an argument about which number is right.

A simple test: count the hours your team spends each month moving or checking data between systems. In most businesses with 10 to 50 staff that I have worked with, the honest answer is somewhere between 40 and 120 hours a month. That is a part-time salary spent on keeping software in sync.

Seven signs you have outgrown your tools

You do not need an ERP because you reached a certain revenue. You need one when the cost of coordination is higher than the cost of change. These are the signs I look for:

1. Month-end close takes more than five working days, mostly because of reconciliation.
2. You have oversold at least once in the last quarter because two channels shared stock without knowing it.
3. One person is the integration. If they are on leave, invoices, payroll or courier settlements wait.
4. You cannot answer simple questions quickly, such as "what is our gross margin by product this month?" or "how much COD cash is still with couriers?"
5. Customer history is scattered. Orders, support tickets and loyalty points sit in different tools, so nobody sees the whole customer.
6. Every new channel is a project. Opening a second outlet or a new sales channel means another tool and another set of exports.
7. Audit and compliance make you nervous. You cannot show who changed a price, a salary or a stock count, and when.

If three or more of these are true, the question is no longer whether to consolidate, but how to do it safely.

What "integrated" should actually mean

Many products call themselves integrated because they share a login screen. That is not what you are paying for. In a properly integrated ERP, a business event happens once and every module that cares about it reacts. Nobody exports, imports or re-types anything.

The architecture that makes this work is event-driven. Each module owns its own data (orders, stock, the ledger, employees) and publishes events when something meaningful happens: order placed, payment captured, stock moved, journal posted. Other modules subscribe to those events. This is how StoreConsole is built: modules talk only through events and listeners, never by reaching into each other's tables. In practice that gives you three things:

• One fact, one owner. Inventory owns stock levels. Accounting owns the ledger. Nobody else writes to them directly, so they cannot drift.
• Modules you can switch on later. You can start with commerce and inventory, and add HR, payroll or manufacturing months later without re-wiring anything.
• An audit trail by default. Because every change is an event, you can always answer "what happened, when, and who did it?"

Order to cash, step by step

Follow a single sale through an integrated system and the value becomes obvious:

Step	What happens	Owned by
1. Order placed	Online, at the POS, by phone or in a chat — the same prices, tax and checkout rules apply.	Checkout
2. Stock reserved	The quantity is held at the location that will ship it, so no other channel can sell it.	Inventory
3. Payment captured	Card gateway, cash on delivery, bank transfer or agreed payment terms.	Payment
4. Journal posted	Revenue, tax and receivables reach the ledger automatically.	Accounting
5. Courier booked	The delivery engine prices the parcel and books it with the courier.	Delivery
6. Status flows back	Courier updates move the order to delivered, partly delivered or returned.	Order
7. Cash settled	COD collected by the courier is matched to the order and posted.	Accounting
8. Customer remembered	Loyalty points, the CRM timeline and a review invitation follow.	CRM, Loyalty

Eight steps, and the only human decision is packing the parcel. That is the difference between "we have software for everything" and "our software works together".

A phased 90-day ERP roadmap

The single biggest predictor of ERP failure is the big-bang launch: everything switched on, on one weekend, with old systems turned off on Monday. When something goes wrong, and something always does, nobody knows which part caused it.

The alternative is a phased rollout, where each phase goes live and settles before the next one starts. Here is the 13-week plan I recommend for a business with one to five locations.

Phase 0 — Data audit (weeks 1–2)

Before you configure anything, list every tool, who owns it and what data it holds. Then decide the master record for each kind of data: products, customers, suppliers, employees. Clean the obvious problems now: duplicate customers, SKUs that mean two different products, suppliers spelled three ways.

Outcome: a one-page migration map that says where every important number will live after the move.

Phase 1 — Catalog and stock (weeks 3–5)

Load products, variants and barcodes. Set up your locations: warehouse, outlets, and anything in transit. Enter opening stock with its cost, because cost is what makes your margin reports meaningful later. Run a physical count at the end of the phase and compare it with the system.

Outcome: one stock count that every channel reads from.

Phase 2 — Orders and money (weeks 6–8)

Connect checkout, POS and payments. Set up the chart of accounts and let sales post journals automatically. This is the phase where a parallel run pays for itself: keep the old accounting package for one month, close both, and compare. Differences point straight at a configuration issue.

Outcome: books that close from the system, not from spreadsheets.

Phase 3 — People and payroll (weeks 9–11)

Add employees, work schedules, holidays and leave policies. Build salary structures with allowances and deductions. Run payroll once in parallel, then let the posted run create its own journal entry, so salary expense and payable reach the ledger without a person.

Outcome: payroll in one run, linked to attendance and leave.

Phase 4 — Reports and automation (weeks 12–13)

Now that the data is trustworthy, decide which numbers each role should see every morning. Schedule a low-stock digest, a daily sales summary by channel and outlet, and an approval flow for refunds and purchase orders. If you use an AI assistant, start it in read-only mode and let it act only after a person approves.

Outcome: decisions made from data everyone trusts.

Rule of thumb: never start a phase until the previous one has run for at least one full week without manual fixes. A week of calm is cheaper than a month of firefighting.

See a connected back office in action

This short tour shows the accounting side of the loop described above: the chart of accounts, journal entries created by business events, and reports built from them.

The five traps that sink ERP projects

1. Migrating dirty data

Moving ten years of messy records into a new system just makes the mess faster. Migrate open balances, active products, current customers and recent history. Archive the rest in a read-only export you can search when needed.

2. Customising before using

Teams often ask for changes in week one that they would not want by week six. Run the standard process for a month first. Most "must-have" customisations disappear once people see how the integrated flow works.

3. No owner per module

Every module needs one person inside the business who decides how it is used: one for inventory, one for accounting, one for HR. Without owners, configuration decisions are made by whoever shouts loudest.

4. Skipping training for the floor

Managers get the demo; cashiers and pickers get a printed sheet. Then the counter staff create workarounds that break stock accuracy. Train the people who touch the system most, on their own screens.

5. Treating go-live as the finish line

Go-live is the start of the useful part. Plan a 30-day stabilisation period with a daily 15-minute check-in, a shared list of issues and a clear owner for each one.

Measure it: KPIs that prove the ERP worked

Agree on these numbers before you start, measure them in Phase 0, and check them again 90 days after go-live:

KPI	Typical before	Healthy after
Days to close the month	7–12	2–3
Stock accuracy (system vs. count)	85–92%	98%+
Oversold orders per month	Several	Near zero
Hours spent moving data	40–120	Under 10
Unmatched COD settlements	Unknown	Listed daily, cleared weekly
Time to answer "margin by product?"	Days	Seconds

The "before" ranges are what I typically see in small and mid-sized businesses running on separate tools. Your own numbers matter more than mine: write them down now, so the improvement is visible later.

Where StoreConsole fits

StoreConsole was designed around this exact roadmap. Commerce, inventory, POS, delivery, accounting, HR, payroll, CRM and more are separate modules that share one database and talk through events. You switch on only what you need today, add the rest when you are ready, and run it on your own server so the data stays yours. If you want to see the whole loop, the live demo is open, and the ERP overview lists every module.

Key takeaways

• The real cost of disconnected tools is the coordination work between them, usually 40–120 hours a month.
• "Integrated" means one event, many reactions — not a shared login page.
• Roll out in phases: data audit, catalog and stock, orders and money, people and payroll, then reports and automation.
• Run in parallel for one cycle at every money-related phase.
• Agree on KPIs before you start, so you can prove the change worked.

Anichur Rahaman is a software architect and the creator of StoreConsole. He designs commerce and ERP systems for growing businesses, with a focus on event-driven architecture, data integrity and self-hosted operations.