Most systems pain comes from unclear ownership at the boundary between functions.
The boundary is where CRM hands to billing, billing hands to finance, product hands to success, support hands to engineering, HR hands to IT, procurement hands to finance. Each team optimizes its own tool. The business problem crosses all of them.
Ownership boundaries should say who can create, change, approve, merge, retire, and override facts. They should also say when a system may copy a fact for convenience and when it may become authoritative. That second part is where many companies get into trouble. A copied field slowly becomes a place people edit because it is closer to their work.
The boundary between sales and finance is a classic example. Sales may own opportunity stage and forecast category. Finance may own invoiced revenue and payment status. Contract value may involve CPQ, billing, and ERP rules. If nobody defines the handoff, every exception turns into an argument about whose system is "right."
Good boundaries are specific. "CRM owns customer" is too broad. CRM might own account owner and pipeline state. Billing owns invoice state. Product owns usage. Support owns incident history. The warehouse reconciles. Workflow tools coordinate tasks but should not silently create new truth.
This is governance, but not in the abstract policy sense. It is a practical defense against accidental authority.
The operator test: if two systems disagree, who has the right to correct the record, and where does that correction start? If the answer depends on who is loudest in Slack, the boundary is not owned.
This is part 4 of 10 in Systems of Record.
