- of the effort in successful AI programmes goes on people and processes, per BCG
- 70%
- layers of readiness: records, masters, integration, history, governance
- 5
- is a realistic time to make a mid-sized company's core data dependable
- 3 to 9 months
There is a sentence that anyone who has worked on analytics in Nepal has heard many times: "The data is all in the system." It is usually said in good faith, and it is usually wrong in ways that matter. The sales are in the system, but under four spellings of the customer's name. The stock is in the system, but the item list has 9,000 entries for 3,000 products. The purchases are in the system, but entered when the bill arrived, three weeks after the goods. The costs are in the system, but in ledger heads designed for the tax return.
An AI tool given that data does not complain. It produces a forecast, a ranking or a report, in confident prose. The forecast is wrong because the history is wrong. This is the central, unglamorous fact of AI in business: the algorithm is the easy part. RAND's review of why AI projects fail lists the lack of necessary data among the leading causes. BCG's research assigns only 10 per cent of the effort in a successful programme to algorithms.
This article sets out what "ready" means for a mid-sized company in Nepal, how to test it, what it costs to get there, and the order in which to do the work. It is the fourth piece in our series on artificial intelligence for business in Nepal.
Two kinds of readiness
It helps to separate two things that are often run together.
Readiness to assist. Using AI to draft a letter, summarise a contract, write a formula or translate a notice needs almost nothing from the company's data. A company is ready today. What it needs is a usage rule and some training.
Readiness to decide. Using AI to forecast demand, rank receivables, detect unusual transactions, set prices or score credit needs the company's own history, clean and connected. Here most companies are not ready, and no tool will make them so.
The value sits overwhelmingly in the second kind (where the value is). So a company that wants more than convenience has to look at its data honestly.
The five layers of readiness
We find it useful to test readiness in five layers, from the bottom up. Each depends on the one beneath.
Layer 1: Records. Is everything captured, at the source, on time?
Data quality is decided at the moment of entry, by the person at the counter, the store or the gate. The questions:
Is every sale recorded on a system-generated invoice at the time of sale?
Is every purchase recorded when goods are received, not when the bill arrives?
Are stock movements, including transfers, samples, breakage and returns, recorded as they happen?
Are cash receipts and payments entered daily?
Are credit notes, discounts and write-offs recorded as such, and not buried in a net figure?
The common failures in Nepal are specific. Purchases recorded on bill date overstate margins in one month and understate them in the next. Sales entered in bulk at day end lose the time pattern a forecast needs. Discounts given by issuing a lower-priced invoice cannot be seen at all. Stock adjusted once a year at the physical count hides eleven months of shrinkage.
There is a harder point that should be stated plainly. In parts of the market, a share of business is transacted outside the books, or recorded at values that differ from reality, to reduce tax or duty. Apart from being unlawful, this makes analytics impossible. A model cannot forecast sales that were never recorded or cost goods at an invoice value that is not the true value. A company that wants to manage by data has to decide to record what actually happens. The tax office's own analytics, built on invoice data, customs data and third-party matching, are making the alternative steadily more dangerous (the data-driven tax authority).
Layer 2: Masters. Does each thing have one identity?
Master data is the list of things transactions refer to: items, customers, vendors, employees, ledger accounts, cost centres, locations. Every analytical use depends on it, and it is where most Nepali systems are weakest.
Customers and vendors. One party, one record. The PAN is the natural unique key for registered businesses, and using it removes most duplicates. Unregistered parties need a discipline of their own: a phone number or a system code.
Items. One product, one code, with a unit of measure, a category, a brand and a pack size. "Rice 25kg", "Rice 25 KG bag" and "25kg rice" are one item to a person and three to a machine.
Chart of accounts. Ledger heads that serve management as well as statute: revenue and cost by product line, branch or project, so that margin can be read without a spreadsheet exercise.
Employees. One record across payroll, attendance and the Social Security Fund.
A useful test: export the customer list, sort by name, and count the near-duplicates on the first three pages.
Layer 3: Integration. Do the systems agree with each other?
A typical mid-sized company has billing software at the counter, an accounting package in the back office, stock in one or the other or in Excel, payroll in a separate file, bank statements in PDF, and tax data on the Inland Revenue Department's portal. Each is internally consistent. Together they disagree.
Readiness at this layer does not require an expensive enterprise system. It requires three things: that the same codes are used everywhere (the item code at the counter is the item code in stock and in the ledger); that data moves between systems by export and import or a connector, not by retyping; and that the key totals are reconciled monthly. Sales in billing equals sales in the ledger equals sales in the VAT return. Stock in the store system equals stock in the ledger. Payroll equals the salary ledger equals the TDS and SSF deposits.
Those reconciliations are also exactly what an auditor, a lender and a tax officer check. Readiness for AI and readiness for scrutiny turn out to be the same work.
Layer 4: History. Is there enough of it, and is it consistent?
Pattern-finding needs a past. Demand forecasting wants two to three years of daily or weekly sales by item, because festivals and seasons recur annually and must be seen at least twice. Collections ranking wants a year or two of invoice dates and receipt dates by customer. Anomaly detection wants enough normal transactions to know what unusual looks like.
Two local complications. First, the calendar: Nepali business runs on Bikram Sambat months and a fiscal year ending in mid-July, while most tools assume Gregorian months. Dashain and Tihar move against the Gregorian calendar each year. History should carry both dates, and seasonal analysis should be done on the Nepali calendar. Second, breaks: a change of software, a re-coding of items or a merger of branches cuts history in two unless someone maps old codes to new. That mapping is tedious and valuable.
Layer 5: Governance. Who owns it, who can see it, and is it lawful?
Data nobody owns decays. Each core data set needs a named owner, a person and not a department, who is responsible for its quality: the sales head for the customer master, the stores head for the item master, the finance head for the chart of accounts.
Access should follow need. The Individual Privacy Act 2075 and its regulation protect personal information, require consent for collection and limit use to the stated purpose. Employee records, patient records, customer identity documents and bank details are covered. Nepal does not yet have a comprehensive data protection law or a dedicated authority, and there is no general duty to notify breaches, but the direction of policy is clear, and foreign clients and partners already demand more by contract. Before personal data is put into any AI tool, the company should know its basis for doing so, where the data goes and who can see it (AI risk is a governance question).
Backups, simple as they are, belong here too. A company whose only copy of five years of data is on one office computer is not ready for anything.
A 20-question readiness test
Score one point for each "yes". Be strict.
Records
Every sale is invoiced through a system at the time of sale.
Purchases are recorded on receipt of goods, with the bill matched later.
Stock movements are recorded daily, and a physical count is done at least quarterly.
Discounts and credit notes are recorded separately and can be reported by person and customer.
Masters
Each customer and vendor has one record, keyed by PAN where registered.
Each item has one code with unit, category and pack size.
The chart of accounts shows margin by product line, branch or project.
Someone approves every new master record.
Integration
Billing, stock and accounts use the same codes.
Data moves between systems without retyping.
Sales per billing, ledger and VAT return are reconciled monthly.
Bank accounts are reconciled at least monthly, with no unexplained items older than 30 days.
History
Three years of transaction data are available in one consistent coding.
Data carries both Bikram Sambat and Gregorian dates, or can be converted reliably.
The books are closed monthly by a fixed date.
Year-end adjustments are small relative to the monthly figures.
Governance
Each core data set has a named owner.
Access to personal and sensitive data is restricted and logged.
Backups are automatic, off-site and tested.
There is a written rule on what may be entered into external AI tools.
Reading the score. 16 to 20: ready for analytical uses, start with the highest-value one. 10 to 15: ready for some, fix the gaps the chosen use case depends on. Under 10: use AI to assist, and put the investment into the books first. We would expect most mid-sized companies to score in the middle band, with masters and integration the weakest layers.
What each use case actually needs
Readiness is not all or nothing. Each use has a minimum.
| Use case | Minimum data | Usual gap in Nepali companies |
|---|---|---|
| Invoice capture | Vendor master with PAN, ledger codes | Duplicate vendors, bills in mixed languages |
| Bank reconciliation | Bank statements in electronic form, cash book up to date | Statements only as PDF, entries posted late |
| Collections ranking | Invoice date, due date, receipt date by customer for 12 to 24 months | Receipts posted on account, not against invoices |
| Demand forecast | Daily sales by item for 2 to 3 years, stock-out days | Item duplicates, no record of lost sales |
| Discount and price analytics | Landed cost per item, list price, discount on invoice | Discounts hidden in net prices, landed cost not computed |
| Tax reconciliations | Monthly close, sales and purchase registers, portal data | Books closed quarterly or yearly |
| Cash forecast | Receivables, payables, loan schedule, payroll calendar | Payables recorded late, no payment calendar |
| Management commentary | A stable chart of accounts and prior months' reports | Reports rebuilt by hand each month |
The right-hand column is a to-do list. A company can pick the use case it wants and see precisely what stands in the way.
What readiness costs
There is no escaping this part, and vendors rarely mention it. An illustrative budget for a trading or service company with sales of NPR 50 to 150 crore, one main location and a few branches. These are proportions for planning, not quotations.
| Work | What it involves | Typical effort | Indicative cost (NPR lakh) |
|---|---|---|---|
| Master data clean-up | De-duplicating customers, vendors and items, adding PAN, categories and units | 6 to 10 weeks, two people part-time plus guidance | 3 to 6 |
| Chart of accounts redesign | Adding product, branch or project dimensions, mapping old to new | 3 to 4 weeks | 1.5 to 3 |
| Process changes at source | Goods receipt notes, daily entry, discount recording, new-master approval | 8 to 12 weeks to embed | 2 to 4 |
| Monthly close and reconciliations | A close calendar, standard reconciliations, a reporting pack | 3 months to stabilise | 3 to 5 |
| Integration | Connectors or structured export and import between billing, stock and accounts | 4 to 8 weeks | 2 to 8 |
| History repair | Mapping old codes, converting dates, loading three years | 3 to 6 weeks | 1.5 to 3 |
| Governance | Owners, access rights, backup, usage policy, privacy review | 2 to 3 weeks | 1 to 2 |
| Total | 3 to 9 months elapsed | 14 to 31 |
Three comments on the table.
The largest cost is not in it: the time of the company's own people, and the friction of asking a storekeeper, a salesperson and an accountant to change daily habits. That is why BCG puts 70 per cent of the effort under people and processes.
The cost is mostly one-off, and the benefit is mostly independent of AI. A company with clean masters, a monthly close and reconciled systems makes better decisions, borrows more easily, passes its audit faster and defends a tax assessment with less pain, whether or not it ever uses a model (what a monthly management report should include).
The work cannot be bought as a product. Software can help find duplicates and convert dates. It cannot decide which of two customer records is the real one, or persuade a branch to record goods on receipt.
The order of work
Sequence matters, because each layer rests on the last.
First, stop the bleeding. Before cleaning anything, put a gate on new master records: one person approves each new customer, vendor and item. Otherwise the list degrades as fast as it is cleaned.
Second, clean the masters. Start with the 20 per cent of customers and items that make up 80 per cent of the value. Merge duplicates, add PANs, assign categories.
Third, fix recording at source. Goods receipt on arrival. Discounts as discounts. Daily entry. This is a management task, with the managing director's visible backing.
Fourth, establish the monthly close. A fixed date, a checklist, standard reconciliations. Start at day 15 and bring it down (redesigning the close).
Fifth, connect. Only now is it worth spending on integration, because only now is the data worth moving.
Sixth, repair history and assign ownership.
A company that follows this order can begin a first analytical use case around month four, on the cleaned portion of the data, while the rest continues.
From the counter to the cabinet
Data readiness looks different at each level of the economy, and the levels are connected.
At the counter and in the store, readiness is habit: scan the item, do not type a description. Record the breakage. Enter the receipt today. The people doing this are often the lowest paid in the company and the least told why it matters. A half-hour explanation of what the data is used for does more than any software.
In the finance department, readiness is discipline: reconcile, close, explain differences, refuse to carry unexplained balances.
In the boardroom, readiness is priority: funding the clean-up, backing the process changes, and asking each quarter for the readiness score.
Across industries, readiness is uneven. Banks and financial institutions are furthest ahead, because core banking systems and Nepal Rastra Bank's reporting requirements have forced structured data for years. Telecom and large retail follow. Trading, manufacturing, hospitality, health and construction lag, with islands of good practice.
At the level of the state, readiness is infrastructure. The National AI Policy 2082 includes commitments on national datasets, data centres and governance. The National ID and the PAN give the country usable unique identifiers for people and businesses. The Central Billing Monitoring System is, among other things, a very large structured data set of invoices. What the state lacks is what many companies lack: consistent standards, clear ownership, and a modern legal framework for privacy and data sharing. Until a data protection law is in place, the uncertainty falls on companies, particularly those handling foreign clients' data.
The role of consulting and advisory firms
Internationally, data readiness is where much consulting effort on AI is actually spent, whatever the proposal was called. The large firms' published work is consistent on the point. BCG's 10-20-70 rule and McKinsey's finding that high performers redesign workflows, not just deploy tools, both describe a programme that is mostly not about models. The Big Four have built large practices around data governance and finance transformation for the same reason.
For a mid-sized company in Nepal, the equivalent work is modest in scale and close to ordinary good accounting. An adviser can usefully:
run the readiness test independently and tell the board the true score;
lead the master data clean-up and chart of accounts redesign, which need accounting judgement more than technology;
design the close and the reconciliations;
specify what integration is needed, so that a software vendor builds only that;
review privacy and access arrangements against the Privacy Act and client contracts.
What an adviser cannot do is keep the data clean afterwards. That requires owners inside the company.
This is the part of the AI subject closest to our own practice: bookkeeping and monthly close, management reporting and analytics, spreadsheet and dashboard design, process automation and internal controls. We would describe it as putting the house in order. It is not exciting, and everything else depends on it.
The next 90 days
Days 1 to 30. Score the 20 questions, with evidence. Put the approval gate on new master records. Choose the one use case the company most wants and read off its gaps from the table above.
Days 31 to 60. Clean the top 20 per cent of customers, vendors and items. Introduce goods receipt on arrival and separate discount recording. Set a close date.
Days 61 to 90. Run two monthly closes with the three core reconciliations: sales, stock and bank. Name the data owners. Write the one-page rule on external AI tools. Re-score, and report the before and after to the board.
At day 90 the company will not be finished. It will know exactly where it stands, and its books will already be more useful than they were.
Frequently asked questions
Can we skip the clean-up and let the AI tool handle messy data?
For reading documents and drafting, the tools are tolerant. For forecasting, ranking and detection, they are not. Duplicates and late entries produce wrong answers that look right, which is worse than no answer.
We use desktop accounting software. Do we need to replace it?
Not necessarily. The software is rarely the constraint. Clean masters, timely entry and a monthly close can be achieved in most packages. Replace the system when it cannot export data or hold the dimensions you need.
How long does a master data clean-up take?
For a mid-sized company, six to ten weeks for the bulk, if two people give it steady time and someone with authority resolves the disputes. Keeping it clean is permanent.
Why does the Nepali calendar matter for data?
Seasonal patterns follow Bikram Sambat months and festivals that move against the Gregorian calendar. A forecast built on Gregorian months will misplace Dashain demand from one year to the next.
Is personal data in our accounting system covered by privacy law?
Yes. Employee records, customer identity documents and similar information fall under the Individual Privacy Act 2075. Collect what is needed, use it for the stated purpose, restrict access and take care about sending it to external tools.
What is the first thing to fix?
Put an approval gate on new customers, vendors and items today. It costs nothing and stops the problem growing.
Does better data really help with the tax office?
Monthly reconciliation of sales, purchases, VAT and TDS means mismatches are found and corrected by the company before they are found by the Inland Revenue Department's systems. That is the cheapest tax risk management available.
How do we keep staff motivated through a clean-up?
Explain what the data is for, start with the records they use most, show them a report they could not get before, and make quality part of someone's job by name.
*This article is general guidance, not legal or technical advice. Cost and time ranges are indicative and vary by company. Legal points are summarised from published sources as of November 2026 and should be confirmed against the current law.*
