Skip to main content

​
Match evidence without posting it

The W1–W7 workflow is live in the GreatBook web application. Matching answers whether independently recorded facts belong together. It does not compose a document, approve intake, write a journal entry or resolve an Auditor finding. Those boundaries are what make the workflow explainable.

​
The workflow, W1 through W7

​
Worked example: review and reverse a bank match

  1. Open Matching and begin with exactly one bank-evidence line or settlement.
  2. Check its read status and graph freshness before acting. A stale, unavailable or truncated chain is inconclusive, not unmatched.
  3. Inspect candidates and the complete chain. Candidate rules may use exact bank reference, amount/date/party, a unique amount/date or a deterministic batch sum; each remains reviewable.
  4. Review the proposed subject/candidate pair, exact amount and currency, rule, deltas and current version before accepting or rejecting.
  5. To reverse an accepted relationship, choose Unmatch. GreatBook restores the recorded pre-match purpose; a legacy match without a trustworthy restoration value is refused rather than reset to a guess.
  6. On a conflict, reload the committed facts. The UI does this automatically for a version conflict and tells you another writer changed the candidate.
  7. Follow an allocation or exact journal-entry link when the question becomes accounting; follow an Audit link when the question is an exception.
Decision writes are idempotent and concurrency-aware. The decision is tied to the subject and candidate version, so an old screen cannot silently overwrite a newer decision. Amounts remain fixed-point strings from service to screen; do not round a matching amount to make it fit. Matching decisions never post, edit or reverse a journal entry. A lost HTTP response is an unknown outcome, not proof that the decision did not commit. The final workbench re-reads the canonical proposal/match state before offering a retry and keeps the uncertainty visible if that read also fails. Likewise, an unavailable audit-event read remains an error beside the decision controls rather than becoming “no events”. The same W3 accept, reject and undo outcomes are now available through the merged staged-workspace adapter set. That path does not create a generic Matching writer: it binds the proposal UUID, candidate SHA-256 and exact native amount/currency, re-reads the canonical proposal under the verified organization and commits only after exact-revision single-use confirmation. The canonical W3 correction log and the workspace receipt retain the audit evidence, and undo remains the compensation. Public protected MCP ingress is current on registry 1.14.1, but real ChatGPT behavior remains unverified.

​
Read document-chain facets carefully

The W7 facets are read-only views over configured counterparties:
  • Procure to pay covers configured goods-receipt, supplier-invoice, purchase-order, VAT-evidence and debit-advice relationships.
  • Order to cash covers the configured sales-invoice to customer-PO relationship.
  • Float covers the configured reimbursement-voucher to expense-receipt-bundle relationship.
They show a missing-counterparty finding, its age, status, waiver information, source evidence, graph edges and deep links back to review, assurance and matching. Freshness, missing source data, stale projection and unavailable graph tables are surfaced as coverage states; none is displayed as a clean empty facet.

​
Typewriter bank statements

Use the Typewriter to prepare a bank statement only when the intended next step is evidence intake. The handoff preserves the statement as source evidence for matching; it does not create a settlement, apply an allocation, approve a payment or post a journal entry. Continue in Matching, then traverse to Accounting Desk or Ledger only after the respective durable records exist. The evidence-only handoff terminates at evidence_loaded; retry, sweep and dead-letter handling preserve the handoff without turning it into a payment or posting instruction.