Overview
Demo-specific comparison, not a general database benchmark.
The Contract-to-Cash demo reviews invoice adjustments across renewal, amendment, side-letter, overage, and annual-upfront scenarios. It compares Synapsor plus an LLM lane against a Postgres plus app-glue plus LLM lane, with a rules-only lane as a baseline for the easy case.
The Postgres lane can reach the same target decisions, but the application owns retrieval, filters, evidence assembly, proposal workflow, audit, and replay glue. The Synapsor lane uses compact slots, hidden session bindings, selected hybrid evidence, reason codes, write proposals, branch state, settlement policy, and replay records as durable run state.
The metrics below come from the seeded demo artifact at docs/labs/contract-to-cash-metrics-20260519.json, generated from the current Contract-to-Cash demo code. They show this demo's input-token and app-glue reduction; they are workflow-specific and should not be read as a latency claim or a universal cost claim.
Contract workflow ownership
The comparison is about where close-period trust logic lives.
- App assembles invoice rows, raw clauses, policy chunks, approval rules, and replay scaffolding
- App owns close-period tenant filters and billing guardrails
- App owns proposal workflow, audit rows, and replay reconstruction
- The prompt carries larger repeated context
- DB binds tenant, principal, current case, customer, contract, invoice, branch, and close period
- DB prepares compact slots and selected evidence lookup records
- DB stages invoice adjustments as write proposals on branches
- DB keeps settlement and replay semantics close to the data
Synapsor DBMS table design
The Synapsor lane is modeled so contract, invoice, usage, evidence, proposal, and replay state can be governed close to the rows being reviewed.
- customers: customer_id, tenant_id, customer_name - hot_state
- contracts: contract_id, tenant_id, customer_id, contract_number, status - hot_state
- invoices: invoice_id, tenant_id, customer_id, contract_id, invoice_number, status, total_amount_cents - hot_state
- c2c_exception_cases: case_id, tenant_id, customer_id, contract_id, invoice_id, close_period, case_type, risk_level, status - hot_state
- c2c_adjustment_proposals: adjustment_id, case_id, customer_id, contract_id, invoice_id, close_period, proposal_state, proposed billing/revenue adjustment - hot_state
- c2c_audit_events: audit_id, case_id, actor, action, payload, created_at - audit_log
- Synapsor-native branch state: auto branch, diff, settlement, commit, merge, replay record
- Synapsor-native evidence/write proposal resources stay linked to the case, invoice, and proposal lookup ids
- contract_clause_chunks: chunk_id, tenant_id, contract_id, amendment_id, clause_type, title, status, body - searchable_knowledge
- revenue_policy_chunks: chunk_id, tenant_id, policy_id, topic, status, allowed_role, body - searchable_knowledge
- Hybrid retrieval selects contract clauses, side letters, credits, usage approval rules, and revenue policy chunks
- Hidden bindings keep tenant, close_period, customer_id, contract_id, and invoice_id out of model-controlled arguments
Contract-to-Cash table relationship diagram
The diagram uses the local Contract-to-Cash Synapsor SQL schema plus Synapsor-native evidence, branch, settlement, and replay resources.
Sample seed data
Representative seeded cases from the local Contract-to-Cash demo. These are controlled demo cases for explaining workflow ownership, not production customer data.
- C2C-1001 Acme Robotics | Mid-quarter Analytics upgrade plus unapplied SLA credit | expected billing adjustment -$7,000.00
- C2C-1002 BetaCloud | Clean monthly renewal | no adjustment required
- C2C-1003 Northstar Health | Side-letter concession applied to the wrong line | reclass adjustment required
- C2C-1004 MedNova Labs | Usage overage above approval threshold | billing hold required
- C2C-1005 OmniWorks | Annual upfront billing with ratable revenue requirement | revenue schedule required
- POL-REV-001 | Revenue recognition five-step model
- POL-REV-002 | Ratable subscription treatment
- POL-REV-004 | Usage overage approval
- POL-REV-006 | Approval thresholds
- CC-ACME-003 | SLA service credit clause
- CR-ACME-SLA-05 | Approved SLA credit not applied
Seeded demo measured averages
Source artifact: docs/labs/contract-to-cash-metrics-20260519.json. These seeded demo metrics are workflow-specific.
| Category | Metric | Postgres + app lane | Synapsor lane | Result |
|---|---|---|---|---|
| Token pressure | Average input tokens | 5,641 | 1,197 | 78.8% fewer input tokens |
| Token pressure | Average output tokens | 758 | 638 | 15.8% fewer output tokens |
| Token pressure | Average total tokens | 6,399 | 1,835 | 71.3% fewer total tokens |
| Workflow overhead | Average tool calls | 12.4 | 1.8 | 85.5% fewer tool calls |
| Workflow overhead | Average DB round trips | 16.0 | 1.8 | 88.8% fewer DB round trips |
| Workflow overhead | Elapsed in seeded lane | 2.16s average | 1.10s average | demo harness only, not a speed claim |
| Workflow overhead | App-owned glue LOC | 318 | 54 | 83.0% less app-owned glue |
| Trust and audit output | Replay records | 0 | 5 | Synapsor lane keeps replay records |
| Trust and audit output | Write proposal objects | 4 app-managed proposal rows | 4 wrp:// proposals | Synapsor stages write proposals on branches |
| Trust and audit output | App-owned policy checks | 4 ownership points | 0 app-owned points | settlement logic moves into a Synapsor policy |
| Trust and audit output | Rules-only baseline | clean renewal passes | messy cases route to review | LLM lane handles side letters, credits, approvals, and recognition nuance |
Case-level input-token results
Seeded demo cases from the Contract-to-Cash artifact.
| Category | Metric | Postgres + app lane | Synapsor lane | Result |
|---|---|---|---|---|
| Cases | C2C-1001 Acme Robotics | 6,478 | 1,532 | 4,946 saved, 76.4% |
| Cases | C2C-1002 BetaCloud | 5,282 | 1,041 | 4,241 saved, 80.3% |
| Cases | C2C-1003 Northstar Health | 5,511 | 1,144 | 4,367 saved, 79.2% |
| Cases | C2C-1004 MedNova Labs | 5,492 | 1,137 | 4,355 saved, 79.3% |
| Cases | C2C-1005 OmniWorks | 5,442 | 1,129 | 4,313 saved, 79.3% |
Adjustment proposal lifecycle
The Synapsor lane keeps contract-sensitive invoice adjustments branch-staged until policy or review allows settlement.
Closed-period invoice state stays unchanged while the case is evaluated.
Synapsor binds tenant, close period, invoice, customer, and contract state outside model-controlled text.
The capability stages an adjustment proposal with evidence lookup records and reason codes.
Rules can auto-settle only deterministic low-risk outcomes; messy terms remain human-review required.
The adjustment decision can be replayed with the original evidence and policy version.
Developer notes
- This page is based on seeded demo measurements, not a universal benchmark.
- The measured token savings come from compact Synapsor context and handles in this workflow.
- Close-period destructive changes stay behind proposals, settlement policies, and review.
- The page does not make general replacement, HA, SLA, compliance, serverless, or horizontal-scaling claims.