Somewhere in your company, right now, there is a spreadsheet that matters more than the system it was supposed to be a stopgap for. It tracks distributor credit limits, or plantation yield by block, or which invoices are actually overdue. Everyone routes around the "real" system to use it, because it is the version that is actually current.
This is not a scandal. It is how enterprises actually work. The scandal only starts when that file has no named owner, nobody remembers what half the columns mean, and three people are editing three different copies of it right now. The problem was never the spreadsheet. It is the spreadsheet nobody can explain.
Most conversations about "data readiness for AI" jump straight to migration (get everything into one warehouse, one schema, one source of truth) before asking a more useful question: what, specifically, is broken about the spreadsheet you already have?
Spreadsheets are not the enemy
It is worth saying plainly: the spreadsheet is one of the most successful pieces of software ever shipped. It puts structured, ad-hoc, department-specific data modeling in the hands of the person who understands the data best, without a ticket to IT and a six-week wait. That is not a bug in enterprise software adoption. It is the reason spreadsheets never went away no matter how many warehouse projects promised they would.
In most Indonesian enterprises, spreadsheets genuinely are the system of record for something important: a regional sales team's pipeline, a plantation's block-by-block harvest log, an HR headcount plan nobody has bothered to formalize because the formal system is three fields too rigid to capture how the business actually runs. Telling a team to abandon that file before offering something that does its job just as well is how "data initiatives" earn their reputation for taking a year and changing nothing.
The realistic goal is not zero spreadsheets. It is zero undocumented spreadsheets — and that is a much smaller, much faster project.
The four chaos signatures
Before a spreadsheet can be governed, it has to be diagnosed. Four signatures, independently, each predict the same outcome: an AI (or a new hire, or an auditor) that touches this file will get something wrong.
- No owner. Nobody can answer "who do I ask when this number looks wrong." Ownership defaulting to "whoever built it, who left the company two years ago" is the most common version of this.
- No definitions. Column headers like
qty_2oradj_amtthat only make sense to the person who named them. The moment that person is on leave, everyone else is guessing. - Forked versions. More than one copy of the "real" file circulating — usually because someone downloaded it to make an edit and emailed it back, and now there are two currents.
- Manual re-entry. Numbers from this spreadsheet get typed, by hand, into another system further down the chain. Every re-entry is a chance to fat-finger a digit, and nobody upstream will ever know it happened.
Any one of these is a governance gap. Two or more, together, mean the file cannot be trusted as an input to a decision — human or AI — until it is fixed. Notice what is absent from this list: messiness, ugly formatting, or "too many tabs." Those are cosmetic. The four signatures above are structural, and they are the ones worth spending effort on.
The sequence: map, own, connect, promote
The fix is not a project plan with a warehouse at the end. It is a sequence you can run against one spreadsheet at a time, in an afternoon for the simple ones.
| Step | What happens | What it buys you |
|---|---|---|
| Map | List the file, what it tracks, who touches it, and how it moves between people | Visibility: you can no longer be surprised by a spreadsheet you didn't know existed |
| Own | Assign one named person as the accountable owner and have them define every ambiguous column | A single point of truth for "what does this number mean" |
| Connect | Read the file live from wherever it lives (cloud drive, shared folder) instead of exporting or emailing copies | The end of forked versions, because there is only ever one file being read |
| Promote | Migrate to a database only the files that genuinely need concurrent writes, referential integrity, or an audit trail | Migration effort spent only where a spreadsheet has actually outgrown its format |
Most files stop at "connect" and stay there indefinitely, perfectly governed, still a spreadsheet. That is a feature of this sequence, not a shortcoming: it separates "documented and connected" from "moved to a database," which are two different problems that most data programs conflate into one expensive one.
This sequence is also just the practical shape of enterprise data readiness: readiness was never about data perfection, it is about knowing where data lives, who owns it, and whether it can be trusted — spreadsheets included.
What does mapping a spreadsheet actually look like?
Mapping one file is a worksheet, not a project. For a straightforward spreadsheet, a single owner can run all four steps in an afternoon:
- Name it. Write the file's real purpose in one line, such as "distributor credit limits, updated weekly by the regional finance team," so the file stops being an anonymous attachment and becomes a named source with a stated job.
- Source it. Record where the authoritative copy lives and who is allowed to change it. If you cannot point to one location as the real one, that is the fork problem, and it gets fixed here before anything downstream reads it.
- Connect it. Point a live, read-only connection at that one authoritative copy instead of exporting or emailing it. Every reader then sees the same current numbers, and the download-and-fork cycle has nothing left to copy.
- Validate it. Have the owner define each ambiguous column and check a few known figures against reality. Does last month's total match what finance reported? A column nobody can define is a column no AI should be trusted to read.
A fair objection lands right at the connect step. If the file now lives in a shared cloud drive, who can edit the number an AI is about to read? Connecting a spreadsheet does not loosen its permissions. A read-only connection only reads; write access stays with whoever the owner grants it, exactly as before. Per-user permissions then decide who can see a spreadsheet-backed answer, the same way they scope an answer drawn from an ERP. Governance travels with the file instead of being traded away for convenience.
How a connected spreadsheet becomes an AI source
Once a spreadsheet has an owner, defined columns, and a live connection, it is not a second-class citizen next to your ERP or CRM. An AI intelligence layer that queries systems live and applies a shared semantic model does not actually care whether the underlying store is a Postgres table or a well-kept spreadsheet. What it needs is a queryable connection and a definition it can trust.
That is the practical value of doing the map-own-connect work before reaching for a migration: a documented, connected spreadsheet can answer "what is our current plantation yield by block" with the same governance and the same trustworthy definition as a query against a data warehouse. The semantic layer that makes an answer trustworthy is a layer of definitions sitting on top of your data. It does not require every source underneath it to already be a database.
This is also where manual re-entry quietly disappears. Once the spreadsheet is connected live and an AI agent (or a downstream system) can query it directly, there is no more "someone retypes this into the other system every Monday morning." The step that introduced errors in the first place is simply no longer necessary.
When something genuinely should graduate to a database
Some files really do need to become a database, and pretending otherwise just delays a rewrite that is coming regardless. The honest triggers are narrow:
- Concurrent writes. More than a handful of people editing the same rows at the same time, where a spreadsheet's file-locking or last-write-wins behavior starts silently dropping edits.
- Referential integrity. Other systems need to reliably reference rows in this file (a customer ID, a SKU) and a typo in a spreadsheet cell can silently break that link with no error raised anywhere.
- Audit requirements. Compliance, finance, or security needs a record of who changed what, when — something a spreadsheet's version history was never built to guarantee.
Notice that "it's getting big" and "lots of people look at it" are not on this list. Row count and read volume are exactly what a well-indexed, connected spreadsheet handles fine. Graduate on structural need, not on discomfort with the format.
Where Nalar fits
Nalar connects to the systems a company already runs, including spreadsheets, with live, queryable access and per-user permissions, and it applies a shared semantic model so a spreadsheet-backed answer carries the same trustworthy definitions as one pulled from an ERP or a database. Governing your data does not require migrating it first.
If you want to see what a connected, governed data layer looks like in practice, the interactive demo runs on a realistic mock enterprise across six industries. If you are not sure where your own spreadsheets and systems stand today, BARI, our AI-readiness diagnostic, will map it honestly — including the files that need an owner before anything else.
Frequently asked questions
- Do we need to migrate off spreadsheets before using AI?
- No. A spreadsheet that is owned, documented, and connected live is a usable AI source, the same as any database. Migration is a separate decision, not a prerequisite — most enterprises get governed data faster by mapping and connecting what they have than by replacing it.
- How do we know if a spreadsheet is a governance risk?
- Check for the four chaos signatures: no named owner, no documented column definitions, more than one version circulating by email, and numbers that get manually re-typed into another system. Any one of these means the file cannot be trusted as a source without work first.
- What does 'connecting' a spreadsheet actually mean?
- It means the file is read live from wherever it is stored (not exported, emailed, or copy-pasted) so a query against it returns the current version, and every download-and-fork cycle that created chaos in the first place stops happening.
- When should a spreadsheet actually become a database?
- When multiple people need to write to it at the same time without overwriting each other, when other records need to reference its rows reliably, or when you need an audit trail of who changed what and when. Read-heavy, single-owner data rarely needs to graduate at all.