A system of record is the system that owns a piece of data: the one place where that data is created and changed, and the one every other copy defers to when they disagree. If a customer's email differs between two tools, the system of record is right by definition and the other is out of date.
Other systems can store and display the same data, but they are copies. A change made only in a copy will be lost, overwritten or argued about.
A worked example
Take a small company that sells scheduling software. Its customers show up in four places:
- The product's own database, where accounts sign up, invite users and pick a plan.
- A CRM, where sales tracks leads and deals.
- A billing tool, which charges cards and sends invoices.
- An accounting system, which keeps the books.
"Which one is the system of record for customers?" has no good answer, because no single system owns everything about a customer. Ask per field instead:
- Account name, plan, users, feature usage: the product database.
- Deal stage, sales owner, lead source: the CRM.
- Card on file, invoice status, failed payments: the billing tool.
- Revenue and ledger entries: the accounting system.
Each system keeps an ID that points at the others and copies only what it needs to display. The app stores the billing tool's customer ID to show payment status, but it does not decide that status.
class Account < ApplicationRecord
# Owned here: name, plan, users.
# Owned by the billing tool: payment_status. Only BillingSyncJob writes it,
# from the billing tool's webhooks. Nothing in the app edits it by hand.
validates :billing_customer_id, uniqueness: true, allow_nil: true
def payment_overdue?
payment_status == "past_due"
end
end
The comment does real work: whoever adds an admin form next year needs to know payment_status is a mirror, not a field to make editable.
System of record vs source of truth
People use the two terms interchangeably, and that is usually fine. When the difference matters, it is this:
- The system of record is where the data is written. It owns the change.
- The source of truth is where people and programs go to read the agreed answer. It can be the system of record itself, or a place that gathers data from several systems, such as a data warehouse that combines CRM, billing and product data for reporting.
So a warehouse can be the source of truth for last quarter's customer count without owning any single customer. When a team says "we want one source of truth," they usually mean "we want to stop having two systems that both think they own this."
System of record vs system of engagement
A system of engagement is where people interact with the data: a support inbox, a chat tool, a sales app on a phone, a customer-facing portal. It is built for the conversation, not for keeping the authoritative copy.
A support tool showing the customer's plan next to a ticket is fine, as long as it reads the plan from the system of record and sends changes back there. Trouble starts when it quietly becomes a second place where the plan is edited.
How to decide which system owns what
Decide per field, or per small group of fields, not per tool. For each one, ask:
- Where is it created? The system where the event happens (a signup, a payment, a closed deal) is usually the owner.
- Which system enforces the rules for it? Plan limits live in the app; card retries live in billing.
- If two systems disagree tomorrow, which one should win without a meeting?
Write the answers down, even as a short list in the repo, and make the code match: owners write, everyone else reads or syncs one way.
What goes wrong with two systems of record
When two systems both accept edits to the same field, they drift:
- A customer changes their email in the app, sales changes it in the CRM, and a two-way sync keeps whichever ran last.
- Support downgrades a plan in a separate tool, and the app keeps the old limits.
- Reports disagree, and a meeting decides which number is real.
Two-way sync hides the question of ownership instead of answering it. Pick one owner per field and make every other copy read-only.
When an ERP or accounting system is the right owner
Not everything belongs in your own database. The general ledger, payroll and tax filings belong in an accounting system or an ERP, which exist to enforce double-entry rules, period closes and audit history. Rebuilding that in a product app is rarely worth it. The same goes for a manufacturer whose production planning and procurement run in one suite: the ERP owns orders and stock, and other tools read from it. Whether to build those modules yourself is a separate question, covered under custom ERP.
Your app's database is usually the system of record
For a software company, customers, accounts, subscriptions and orders are born in the product. They are your models, and the app enforces their rules every time a customer acts. That makes the app's database their system of record, whether or not anyone called it that.
The common mistake is in the internal tools. A team needs to look up customers, fix a plan or approve a refund, and reaches for a separate tool: a spreadsheet export, a no-code app with its own tables, a CRM fed by a nightly sync. Each is a copy, and the moment someone edits it, you have two systems of record.
The alternative is internal tools that read and write the app's data in place, through the same models and validations the product uses. Support, ops and finance then edit the record itself. Whether to build or buy those tools is its own decision, covered in build vs buy internal tools.
Doing it with Avo
Teams that keep the app as the system of record often build their internal tools with Avo, which runs inside the Rails app over the existing models, so there is no copy to sync. The Rails CRM and Rails ERP pages show what that looks like for sales and operations data, and rewrite your admin covers replacing an existing admin without a big cutover.
Frequently asked questions
What is a system of record?
A system of record is the system that owns a piece of data. It is where that data is created and changed, and when another system holds a different value, the system of record is the one that counts.
What is the difference between a system of record and a source of truth?
A system of record is where data is written and owned. A source of truth is where people go to read the agreed answer, which may be the system of record itself or a place like a data warehouse that combines several systems. In everyday use the two terms mean almost the same thing.
Is the CRM or the ERP the system of record?
It depends on the data, not the tool. The CRM usually owns sales data such as deal stage and sales owner, the ERP or accounting system owns ledgers, payroll and often stock and purchasing, and for a software company the product database usually owns customers, accounts and subscriptions. Decide ownership field by field.
Should custom internal tools replace the system of record or sit beside it?
Neither. Internal tools should read and write the system of record's data in place rather than keep their own copy. A tool that must keep a copy should treat it as read-only and send changes back to the owner.
What happens if two systems are both the system of record?
They drift apart. Edits in one system overwrite or miss edits in the other, and reports disagree. Choose one owner for each field and make every other copy read-only.
