The question that has no answer

Ask a room whether the CRM or the accounting system should be the source of truth, and you will get a ninety minute meeting and no decision. I have sat through that meeting more than once. It goes nowhere because the question is the wrong size. The development lead is thinking about a donor's phone number. The controller is thinking about the amount that hit the bank. Both of them are right, and they are not discussing the same problem.

The unit of ownership is not a system. It is a field.

Ownership belongs to a field, not a system

A system of record is not a tier in your stack. It is a claim about one piece of data: when two places disagree about this value, this one is right, and the other one is wrong and needs fixing.

That claim can only be made field by field. Your payment processor is authoritative for what was charged, to the cent, because it is the thing that did the charging. It is not authoritative for what that charge was for, or which period it belongs to. Your CRM may well own a constituent's mailing address and have no business holding an opinion about whether a pledge was fulfilled.

Once ownership is written down at that level, the argument usually stops. What looked like a turf dispute between two departments turns out to be five or six rows where the answer is obvious as soon as somebody says it out loud, and two rows that are genuinely hard. Those two are the actual work, and they were invisible while the conversation stayed at the level of whole systems.

The test is who repairs it

The cleanest test I know is this: when a value is wrong, where does a person go to fix it?

Not where the fix shows up. Where a human being types the correction. That system owns the field, whether or not anyone designed it that way.

Say it out loud about a few real fields and the trouble surfaces fast. If a bad mailing address gets corrected in the CRM by the development team, and also corrected in the billing system by whoever happens to be on the phone, you do not have a source of truth with a sync issue. You have two owners, which is the same thing as none. Those two records will drift, and the drift stays invisible until a mailing goes out to an old address or an audit asks which one you were using.

Every other copy needs a direction and a lag

Once a field has one owner, every other place that value appears is a copy. Copies are fine. Most working systems are full of them. What is not fine is a copy that nobody can describe.

For each one, two things should fit in a sentence: which way it flows, and how far behind it is allowed to be. The address flows from the portal to the CRM, within a few minutes. The charge amount flows from the processor to the ledger, overnight. Either of those is a defensible design. What is not defensible is the copy where the honest answer is, I think it goes both ways.

Two way sync on a field that has one real owner is a slow leak. It works until two people edit the same record on the same afternoon, and then it quietly picks a winner on your behalf. I have spent more hours untangling bidirectional syncs somebody set up years ago than on almost any other kind of cleanup. Picking a direction and switching one half off is cheap. Finding the records that already diverged is not.

The three fields that cause the most trouble

Across the operations I have worked in, the same three families account for most of the pain.

Money amounts

The processor owns what was charged. The ledger owns what it was for and which period it lands in. Trouble starts when the ledger also believes it owns the amount, usually because somebody once fixed a fee there instead of at the source, and it worked.

Identity and contact details

Owned wherever the person themselves can change it. If you have a portal where a customer or donor updates their own email, that portal owns the email, whatever your CRM believes. Any other arrangement means you overwrite what somebody told you on purpose.

Status

Fulfilled, active, approved, closed. Status is the field two systems most often both think they own, because each one runs a workflow that turns it. This is the row worth arguing about, and the one worth settling before anybody writes code.

What an unowned field actually costs

The bill arrives in three places, and none of them look like a data problem when they land on your desk.

Reconciliation stops closing cleanly. Somebody spends the first few days of every month deciding which of two numbers to believe. That work never gets faster, because it is not a process being run, it is an argument being relitigated monthly by whoever is available.

Reporting turns political. Two directors bring two dashboards to the same meeting, both technically correct, and the meeting becomes about whose number counts. The real disagreement is not strategic. It is that nobody ever decided which system was right about revenue recognized.

Automation stalls. This is the one that catches people out. Every workflow you want to automate, and every AI assisted step you want to put on top of it, has to read a value and act on it. A field with two owners cannot be automated safely, because the automation has to choose one, and now that choice lives in code instead of in a policy anybody can read. When an automation project dies quietly in scoping and nobody can say quite why, this is often the reason.

The afternoon that settles it

This does not call for a data governance program. It needs one table and the two or three people who actually touch the data.

List every field that shows up in a decision or on a report. For most mid-sized operations that is fifteen to thirty rows, not hundreds. Then fill in four columns.

The rows you can fill in without discussion are already working, and you have now written them down, which is worth the hour by itself. The rows where the room goes quiet are your real integration scope. That last row in the table is the one I would expect to find in most operations, and it is the one that will cost you the most to leave alone.

Do this before the build rather than after. Choosing an owner on a whiteboard costs an afternoon. Changing an owner once two systems and four reports depend on the old arrangement costs a project.