System of Record: Why Results Outside It Don't Exist for Your Company
When we built a proposal generator, the most underrated part wasn't document assembly — it was one technical step: the finished document was automatically attached to the deal record. That didn't save the sales rep time. It determined whether the document existed for the company at all.
A system of record — the system where a company's truth about a deal, a document, or a customer actually lives — isn't an architecture concept. It's a management one. Every fact in a company has a place where it counts as real. If a piece of work never reaches that place, it never happened for the organization, no matter how good it was.
Automation only counts once its output lands in the system of record. A result left sitting in a chat, a spreadsheet, or an email doesn't transfer to the next person, doesn't show up in a report, and doesn't survive its author going on vacation. Data on spreadsheet errors and corporate record quality shows what it costs to keep the truth outside the system: defect rates run into the tens of percent.
System of Record: A Working Definition and Four Warning Signs
You don't spot this problem in the architecture — you spot it in conversation. Each of the four signs below is a symptom of the same thing: the truth about a fact lives somewhere nobody guarantees it.
"I'll send you the file." The only current version of a document exists on one person's machine and gets passed along by hand. A month in, nobody knows which version is the latest — and six months in, not even the author does.
"Ask her, she handled this client." The truth about a deal lives in one employee's memory. That works right up until vacation, a transfer to another team, or a resignation — and never after.
"The report doesn't match reality." The system's data describes part of the work, while decisions get made about another part that never made it into the system. A manager sees a correctly built report on incomplete data and has no way to notice.
"We have a spreadsheet where everything's right." The most dangerous case, because it looks like a solution. The spreadsheet becomes a shadow system of record: people trust it and cite it, but it has no access control, no change history, and no validation.
| Where the truth lives | What happens when the author leaves | Is it visible in reporting |
|---|---|---|
| System of record | Nothing — the fact stays accessible | Yes |
| File on an employee's machine | The current version gets lost | No |
| Employee's memory | The fact disappears entirely | No |
| Shadow spreadsheet | The fact stays but stops updating | No — and this is the most dangerous case |
The third column explains why this problem survives for years. Three cases out of four are invisible in reporting, and they surface only once something has already broken.
What a Shadow Spreadsheet Actually Costs
The spreadsheet as a store of truth has been studied more than people assume — there are both field audits and controlled experiments on it.
Field audits of corporate spreadsheets found errors in 24% of 367 files reviewed, and under more rigorous audit methods that share rose to at least 86%. In controlled experiments, 51% of participants made an error while building spreadsheets of just 25–50 cells.
This is a survey paper pulling together disparate and partly dated studies, and the share of "spreadsheets with errors" depends heavily on how strict the criterion is and how large the file is. That's a real limitation. But the spread from 24% to 86% is informative on its own: the harder you look, the more you find — exactly the property a system with input validation doesn't have.
Data Quality at the Point of Entry
The other half of the problem is what actually gets entered into the system of record itself. There's a measurement here that used an unusual — and for that reason convincing — method.
Only 3% of organizations scored at an acceptable level on data quality, and 47% of newly created records contained at least one critical error.
The sample is small — 75 organizations — and participants collected their own data, which creates a real risk of bias; this is a business-magazine column, not a peer-reviewed publication. What's valuable is the method: manually checking a hundred consecutive records is something any company can repeat in a single day, and it produces a number you can actually act on. I'd recommend starting there, not with an architecture discussion.
Why Companies End Up With More Than One System of Record
The idea of a single unified system runs straight into the reality of the corporate application landscape — and that reality has been measured.
The average number of applications used by a single organization reached 101 — crossing the hundred mark for the first time.
This is telemetry from one identity-management vendor's customer base, not a random sample of companies, and the metric is calculated at the organization level, not the individual level. The practical conclusion still holds: there won't be one single system of record. A realistic goal isn't "one tool for everything" — it's an explicit decision about which system is the source of truth for each class of facts, and a firm ban on duplicating that class anywhere else.
A side effect of this fragmentation is context switching. Here it pays to be precise: the experimental evidence isn't as clear-cut as commonly assumed.
In a controlled experiment, interruptions didn't slow task completion — participants actually finished faster (20.3–20.6 minutes versus 22.8 in the baseline condition). But that speed came at the cost of significantly higher stress, frustration, and time pressure.
This is a lab study with a student sample and an artificial task — you can't map it directly onto hours of corporate work. But the result is useful precisely because it cuts against expectation: the cost of fragmentation shows up not in lost minutes you can see in a report, but in a load that never appears in any report at all. It's the same class of defect without an observer that I wrote about separately.
How to Assign a System of Record
The second step usually triggers an argument, and it's a useful one: it turns out two systems are competing for the same class of facts, and nobody has ever decided which one is authoritative. The decision gets made once, and it costs less than any integration project.
The fourth step applies to AI use cases quite literally. An assistant that answers in a separate window and writes its output nowhere increases the number of places truth is stored — it doesn't reduce it. The question "where does the result land" deserves to be asked before "how good is the answer."
Four Checks You Can Run in One Day
Pull your last hundred records
Check them by hand for obvious errors: empty required fields, contradictions, duplicates. The defect rate is your baseline.
Find the shadow spreadsheets
Ask where the "correct" version of the data lives. Every spreadsheet named in the answer is a class of facts with no system of record.
Assign a system of truth to every class
Deal, document, payment, inquiry, counterparty. One place per class, the decision written down.
Check every process for delivery
Trace where the output ends up. If the answer is "in the correspondence" or "with whoever did the work," the process isn't finished.
If the answer to "where do I find the real version" is a person's name rather than a system's name, automation of that process hasn't started yet.
Frequently Asked Questions
What is a system of record, in plain terms?
It's the system where the company keeps the authoritative version of a fact: a deal, a document, a payment, an inquiry. The test is simple: when two sources disagree, whichever one has been designated the system of record is right, and the other one is a copy. Without that designation, a discrepancy turns into an interdepartmental argument with no way to resolve it.
Can a spreadsheet serve as a system of record?
For small volumes and a single user, yes — provided that's a deliberate, documented decision. The problem arises when a spreadsheet becomes a system of record by default: it has no access control, no change history, and no input validation, and field audits put the share of files containing errors in the tens of percent. It's not the spreadsheet that's dangerous — it's its undesignated status.
What if there are several systems and you need all of them?
Split by class of facts, not by system. A deal can have one system of truth, a payment another, a document a third — that's fine. What's not fine is the same class living in two places at once, both updated by hand: in that case a discrepancy is inevitable, and it will surface at reconciliation time, which is the latest possible moment.
Where should an AI assistant write its output?
Into the same system where the corresponding class of facts already lives, and at the moment the result is produced — not left to the user's discretion. An assistant whose output has to be copied by hand adds one more place where truth is stored and one more point of failure. The practical readiness test for a use case: the result is visible to a colleague who wasn't part of the request.
The mechanics of automatically attaching a finished document to the deal record, and sending it from that record, come from the product description of Alego.Digital's own proposal generator; the company used Megaplan as its system of record. The counterparty-verification integrations with several CRMs (Megaplan, Bitrix24, 1C, amoCRM) come from the description of a second in-house product from the same period. These are the author's own company materials; they haven't been independently verified and are presented here to illustrate the mechanics. The four-way classification of where truth gets stored is the author's own synthesis of practice.
- Panko R. R. What We Know About Spreadsheet Errors. EuSpRIG, 2000; arXiv:0802.3457, 2008. arxiv.org
- Nagle T., Redman T. C., Sammon D. Only 3% of Companies' Data Meets Basic Quality Standards. Harvard Business Review, September 2017. hbr.org
- Okta. Businesses at Work 2025, March 2025. okta.com
- Mark G., Gudith D., Klocke U. The Cost of Interrupted Work: More Speed and Stress. CHI 2008. ics.uci.edu