The Exception Is the Work
Most operations software records activity. A purchase order is approved, a payment arrives, a field report is uploaded, a dashboard changes colour. The difficult question comes later: did the organisation meet its obligation, and can someone show why they believe it did?
That question exposes a gap between systems that record events and systems that support decisions. A contract, policy, or regulation says what should happen. Payment systems, CRMs, ERPs, and field tools record fragments of what did happen. People still have to join those fragments, judge the mismatch, decide what to do, and leave a record another person can inspect.
Evidence-backed operations is a governed layer between systems of record and consequential decisions. It tests an important claim or obligation against operational evidence, then routes exceptions to an accountable action.
The same structure appears in risk review, audit preparation, receivables, claims, supplier qualification, grant management, and fraud control. Its first question is concrete:
Is this claim true under the applicable rules, what supports that answer, and who owns the next action?
I use a home-health documentation-to-claim workflow as a running case. It illustrates the operating pattern; it is not clinical, coding, billing, or compliance advice. The result depends on field documentation, review, coding, submission, and payment records that someone else must be able to inspect and trust.
Use this pattern to find valuable work in the seams between systems, teams, and obligations.
The gap between intent and reality
Documents state intended conditions: a contract sets a delivery milestone, a policy requires approval, a lease specifies rent and a due date, and a rule defines eligibility.
Operational systems record events: deliveries, approvals, bank transactions, receipts, messages, GPS data, and accounting entries. Each source may be useful. None necessarily settles the question on its own.
The layer sits between records and decisions. It preserves the reasoning that connects them.
Business intelligence shows patterns across a portfolio. A report can show an increase in denied claims or a rising number of visits with incomplete documentation. The governed layer traces that signal to the case level: which obligation is unresolved, which records support the assessment, which rule was applied, and who must act. Reporting becomes more useful when it can move between those two levels, from an operational signal to a reviewable case and back again.
BI identifies where attention is needed. The case layer records why a decision was made.
A claim is not proof
Consider a home-health agency deciding whether a completed visit is ready to support a claim. “This visit is ready for payment submission” is the claim. The visit record, clinician note, timestamps, coding, review, and required attachments are the evidence. A reviewer assesses those records against the agency’s workflow and payer requirements, then submits the claim or routes it for correction.
The product value appears at the handoffs: it keeps the case intact when records cross tools, teams, and time.
Each part can fail differently. A visit note may be incomplete. The selected code may not match the documentation. A required review may be missing. A submission may fail downstream, or a payer may return a denial that needs follow-up. A useful workflow keeps those states visible.
The workflow should retain evidence with its source and context. A useful minimum is the source, capture time, effective time, submitting actor, related object, verification state, and version. A reviewer should be able to ask: what did we know when we made this decision?
Where the value is trapped
The hard part is often the handoff between systems of record. In a typical home-health workflow, a visit, note, review, EHR record, coding or claim-preparation step, and payment response can each live in a separate tool or belong to a different team. Each record may be correct locally while the relationship between them remains implicit.
People bridge those gaps with memory, messages, spreadsheets, copied fields, and reports. This adds translation cost and makes the process depend on personal knowledge: someone has to remember what a record means, where it came from, and whether an earlier decision still holds.
A governed layer need not replace every system. It can connect source records, preserve the translation between them, and expose unresolved cases. It reduces rework, preventable denials, late corrections, and the cost of reconstructing an audit trail after the fact. That frees people to spend more time on the judgement, care, customer work, and business decisions that improve the operation itself.
The pattern already works
Each example puts a governed layer between systems of record and consequential decisions. The layer gathers evidence, reconciles incomplete or conflicting state, routes exceptions, and preserves accountability. Its records can later support audits, reporting, and customer trust.
The examples below are vendor-reported customer cases. They do not prove that every workflow can be automated well. They suggest a recurring product shape and the kinds of outcomes buyers pay for.
Ramp helped prompt this line of thought: spend, receipts, approvals, accounting entries, and close tasks can stay connected instead of being rebuilt at month end. Its Shortcut customer story reports closing the books five times faster.
| Product | Workflow | Reported result |
|---|---|---|
| BlackLine | Reconciliations and financial close across accounting systems | Northern Oil and Gas reports 100% automated bank reconciliations and 95% automation of its cash-flow statement. |
| HighRadius | Payments, remittances, invoices, and ERP records | Parikh Financial reports a 99% invoice hit rate and 50% less cash-posting time. |
| Waystar | Claims, payer responses, denials, appeals, and collections | Proliance Surgeons reports claim-status work falling from 15 minutes to two, alongside a 33% productivity increase. |
The products have different buyers and architectures. Across these examples, the workflow is similar: records spread across systems become a reviewable case; resolved cases inform reporting and trust.
The exception is the unit of work
Many cases should not require a human to rebuild the whole story. The valuable work begins when expected state ≠ observed state.
An exception is a case with enough context for an owner to resolve it.
| What makes an exception resolvable | Why it matters |
|---|---|
| The gap | Defines expected versus observed state. |
| Evidence needed | Shows what would settle the case. |
| Rule and consequence | Makes the assessment reviewable and prioritised. |
| Owner and deadline | Turns detection into accountable work. |
| Resolution record | Preserves the decision, action, and proof of closure. |
The difference is structural. A document repository stores material. A dashboard aggregates it. A workflow tool assigns tasks. An evidence-backed operating layer connects all three to an obligation and retains the reasoning and outcome. It lets a team ask why a case is open, what will close it, and whether the same rule was applied elsewhere. Software can reconcile stable rules and records; people should own ambiguous interpretations, policy exceptions, and consequential approvals.
Where AI belongs
AI is useful when evidence is unstructured or a case needs explanation. It can extract candidate terms from a contract, classify incoming documents, identify likely matches, summarise a case file, or propose the next investigation. It can also help a reviewer identify conflicting evidence.
Do not treat AI output as the record of truth. For consequential writes, the system needs deterministic checks where possible, clear confidence and limits where interpretation is involved, and validation or approval before a state change. Persist the model input, relevant source version, result, reviewer decision, and any override when those records affect the outcome.
The test is whether a reviewer can reproduce a material result from the retained evidence and rule version.
Why this is more reachable now
Small teams can now build extraction, mapping, and investigation workflows without creating every component from scratch. Current language models can extract candidate fields from documents, map records across systems, draft case summaries, propose next checks, and handle the repetitive edge of an exception queue. Workflow platforms can connect common systems quickly enough to test a narrow operational loop before a team invests in bespoke integrations.
Where the opportunity appears
This pattern creates opportunities for vertical products and specialised services. Look for recurring obligations with fragmented evidence, costly exceptions, and a clear consequence when the work fails. Those conditions create openings for a governed layer, delivered as workflow software, a service, or both. The return is not only a cleaner audit or regulatory submission. It is less money lost to mistakes and less operating time spent proving routine work, leaving capacity for work that creates value for the business.
Wherever an organisation relies on ERPs, specialist tools, spreadsheets, and human handoffs to prove important work was done correctly, there may be a worthwhile governed layer to build.
The long-term asset
A workflow that preserves obligations, evidence, exceptions, decisions, and outcomes accumulates a useful history. Once that history becomes comparable across cases, it may support better reporting, risk analysis, dispute handling, audit work, or future automation.
The history is useful only if the workflow distinguishes a claim from its proof, an event from a decision, and a late record from a late action. Each resolved case then gives the next reviewer a clearer basis for inspection and, where justified, automation.
Build the layer where a routine claim needs proof. Make ordinary cases easy to verify, and give people the evidence and authority to resolve the ones that are not.
Related
- Reviewing agent-assisted technical work applies the same evidence-and-decision loop to agent-assisted engineering work.
- Vertical Operating Systems: One System of Record to Rule Them All argues that a vertical operating system can own more of a company workflow. This essay focuses on the governed layer that can sit between existing systems of record.
- Event abstraction in process mining explains a technical version of the problem: CRM and ERP systems often record the same work at incompatible levels of detail.
- When Operations Outgrow ERP Workflows, Excel Quietly Becomes the Real System is a practitioner essay on spreadsheets as the visible symptom of an operational gap.
- The timeless appeal of vertical SaaS gives the market case for software that encodes industry workflow, economics, and regulation.