> ## Documentation Index > Fetch the complete documentation index at: https://docs.vinmake.com/llms.txt > Use this file to discover all available pages before exploring further. # Match evidence without posting it > The W1–W7 matching workflow: independent bank evidence, controlled decisions, assurance links and document-chain facets. # 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 | Wave | Operator outcome | What it does not mean | | --------------------------- | -------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | **W1 · foundation** | Import and read bank evidence, settlements and their chains. | Importing a statement never posts the GL or guesses purpose. | | **W2 · enrichment** | Read scoped evidence, provenance, freshness and candidate context. | A suggestion is not an accepted match. | | **W3 · durable decisions** | Accept, reject, manually match, unmatch or classify purpose with version-aware writes. | A repeat request creates no duplicate decision. | | **W4 · assurance** | Follow residuals and findings into the Audit register. | Matching cannot mark an assurance finding resolved. | | **W5 · workbench** | Work the queue, selected subject, candidate set and full chain together. | Actions are unavailable when coverage is stale or partial. | | **W6 · Typewriter handoff** | Hand a bank statement as evidence into the matching lane. | The Typewriter statement is evidence-only, not a payment instruction or GL post. | | **W7 · document chains** | Read configured procure-to-pay, order-to-cash and float facets. | A facet never invents a missing document or offers a correction action. | ## 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. ## Related * [GreatBook workspaces](/greatbook/guides/greatbook-workspaces) * [Two layers on the same documents](/greatbook/two-layers) * [Working the exception register](/greatbook/guides/work-the-exception-register)