A bounded, review-first workflow for source extraction, candidate matching, exception visibility and human reconciliation
A reviewer-ready workbook is not the same as completed bank reconciliation.
Executive summary
- An invoice status and a bank transaction are different evidence objects. A “paid” invoice does not by itself establish that an incoming credit was booked in the scoped bank evidence.
- The workflow starts with two bounded snapshots: customer invoices and incoming bank credits.
- Exact references, amount, currency, booked status and approved scope may support a rule-supported deterministic candidate. They do not by themselves prove payer identity or completed reconciliation.
- Ambiguous cases remain model-assisted candidate suggestions or visible exceptions. A confidence score is not a reconciliation decision.
- The output is an illustrative reviewer-ready workbook / output contract followed by human reconciliation and sign-off.
- Humans still approve source scope and matching rules, resolve overrides and exceptions, determine accounting treatment and decide whether reconciliation is complete.
A paid invoice status is not a bank posting
A paid invoice status is not a bank posting. A bank posting is not a completed reconciliation.
An invoice system, a bank feed and a payment-status object report different states. Their records can support a review when identifiers, dates, statuses, references and source scope remain visible. They cannot by themselves prove invoice validity, payer identity, payment finality, accounting treatment or completed reconciliation.
The bounded role for AI is to prepare evidence, apply approved rules, surface unresolved cases and make the handoff reproducible.
Bounded AR / cash-application scope
This piece is not a general payments memo; it is a bounded AR cash-application workflow demonstration.
Invoice source → Invoice snapshot → Bank snapshot → Matching rules → Candidate matches → Exception queue → Human review → Sign-off
In scope:
- invoice-source and incoming-credit snapshots;
- normalization and source lineage;
- rule-supported deterministic candidates;
- model-assisted candidate suggestions;
- visible exception classification;
- an illustrative reviewer-ready workbook and memo;
- human reconciliation and sign-off.
Out of scope:
- supplier AP payment execution;
- beneficiary-master approval;
- full bank-to-general-ledger reconciliation;
- journal posting;
- period close;
- fraud adjudication;
- certification that an account is reconciled.
A bounded workflow is more reproducible than a broad “reconcile everything” claim because it defines which records entered the run, which rules were applied and which items remained unresolved.
Two evidence objects
Invoice-side snapshot
| Evidence group | Fields to retain, where available | What it can support | What it cannot prove |
|---|---|---|---|
| Identity | Stable invoice ID, display number, customer ID/name | Source-system lineage and candidate references | Customer identity or bank receipt |
| Dates | Issue date, due date, created and modified timestamps | Billing context and snapshot freshness | Bank cutoff or payment finality |
| Amounts | Currency, totals and source-specific due/paid fields | Amount and currency matching inputs | That a credit belongs to this invoice |
| Lifecycle | Invoice/payment status, void, amendment and credit-note links | Operational state and exception triggers | Cash receipt or accounting treatment |
| Linkage | PO/reference, linked-service IDs and source record | Additional candidate evidence | Completed reconciliation |
| Extraction | Query, version, pagination and retrieval timestamp | Reproducibility within the declared scope | Completeness outside that scope |
Sequence’s Get an Invoice by ID and List all Invoices documentation shows invoice identifiers, statuses, amounts, dates, customer fields, timestamps, linked records, filters and pagination. Source-specific due, paid or payment-link fields should be retained only when the selected source actually exposes them.
Bank-side snapshot
| Evidence group | Fields to retain, where available | What it can support | What it cannot prove |
|---|---|---|---|
| Scope | Provider and safely masked account identifier | The declared account perimeter | Ownership or completeness across all accounts |
| Identity | Transaction ID, reference, end-to-end ID or UETR | Bank-side or payment-chain traceability | Invoice validity or application decision |
| Counterparty clues | Remittance text and payer metadata | Candidate narrowing | Verified payer identity |
| Dates | Booking date, value date and retrieval timestamp | Lifecycle and cutoff review | Accounting treatment |
| Amount | Amount, currency and credit/debit indicator | Rule-based matching inputs | Fee, FX or gross-to-net conclusion |
| Lifecycle | Pending/booked state and reversal or return linkage | Transaction state and later-change evidence | Finality or completed reconciliation |
Official Open Banking transaction documentation distinguishes transaction identifiers, references, booking dates, value dates, amounts, currencies and transaction statuses. Capital One’s Data Access documentation provides a bank-specific example of account, amount, credit/debit, status and BookingDateTime fields. These sources do not establish universal field availability or bank-feed completeness.
The source timestamp and retrieval timestamp matter on both sides. An invoice can be amended, a pending transaction can post with changed details, and—depending on the payment rail—a later return or reversal may require the earlier application to be reopened.
Run metadata and reproducibility
A reproducible run should capture:
- source systems and safely redacted entity/account scope;
- date range, timezone, status and currency filters;
- inclusion and exclusion rules;
- pagination, limits and query parameters;
- API or export version;
- source-snapshot and generated-at timestamps;
- invoice and bank record counts;
- invoice and incoming-credit control totals;
- mapping and matching-rule versions;
- unresolved-exception count;
- source references.
A spreadsheet without scope, timestamps, versions and control totals may be convenient, but it is not reproducible.
Reproducibility allows another reviewer to understand and rerun the same bounded logic. It does not prove correctness or bank-feed completeness.
Matching model
1. Rule-supported deterministic candidates
An exact candidate may require:
- an exact invoice or remittance reference;
- exact amount and currency;
- a booked incoming credit;
- the approved account and date scope;
- no conflicting void, credit, reversal or lifecycle evidence.
Deterministic rules do not guarantee complete reconciliation. The reviewer still confirms the entity, obligation and source evidence.
2. Model-assisted candidate suggestions
Model assistance may help when:
- a reference is missing or truncated;
- payer names require normalization;
- one incoming credit may cover several invoices;
- several receipts may cover one invoice;
- a fee, FX path or date-window difference may explain a residual;
- a pending record may later become a posted record.
The model may rank candidates and explain the fields used. Model suggestions do not remove human review and should not silently force a match.
3. Human decisions
Humans decide:
- ambiguous and identity-sensitive matches;
- manual overrides;
- cutoff and timing questions;
- accounting treatment;
- unresolved exceptions;
- reconciliation and sign-off.
A confidence score is not a reconciliation decision. Amount and date alone do not prove payer identity. The best candidate is not automatically confirmed.
Exception queue
Exceptions should expose uncertainty and ownership without assigning blame.
| Exception | Evidence trigger | Reviewer question | Owner | What not to infer |
|---|---|---|---|---|
| Unmatched invoice | No booked-credit candidate | Late cash, wrong scope or still open? | AR reviewer | Not bad-debt evidence by itself |
| Unmatched bank credit | No invoice candidate | Missing remittance, suspense or another obligation? | Treasury / AR | Not automatically an error |
| Ambiguous match | Several plausible candidates | Is one application sufficiently supported? | Controller / AR | Highest model score is not sign-off |
| Partial payment | Credit is below the open amount | How should the residual be handled? | AR reviewer | Not an automatic write-off |
| Overpayment | Credit exceeds the open amount | Refund, credit or suspense? | AR / treasury | Not automatically a prepayment |
| Fee / net settlement | Possible gross-to-net difference | Is the fee or settlement path documented? | Finance operations | Net amount is not invoice value |
| Credit note | A credit changes the invoice balance | Which adjusted amount governs? | AR / controller | Original invoice total is not final evidence |
| Voided or amended invoice | Source changed after extraction | Which version governs? | AR / controller | Old snapshot is not authoritative |
| Pending-versus-posted conflict | Linked lifecycle records | Transition or actual duplicate? | Treasury reviewer | Two rows do not mean two payments |
| Date / cutoff mismatch | Evidence falls across periods | Which evidence belongs in the review period? | Controller | Operational timing is not accounting treatment |
| Missing remittance reference | Amount/date without usable reference | Is payer and obligation evidence sufficient? | AR reviewer | Amount/date do not prove identity |
| Reversal / return | Later opposite or return entry | Should the earlier application reopen? | Payment operations | Initial booking may not remain final |
| Manual override | Reviewer forces a result | What evidence and approval support it? | Controller | Override is judgment, not proof |
Exceptions are not fraud, misstatement, accounting-error or control-failure conclusions.
Illustrative reviewer-ready workbook / output contract
| Tab | What it supports | What it does not prove |
|---|---|---|
Run_Metadata |
Scope, queries, timestamps, versions, counts and control totals | Source completeness or correctness |
Invoice_Snapshot |
Invoice-side evidence at extraction time | Bank receipt |
Bank_Transactions |
Bank/provider evidence within the declared scope | Invoice validity or full-feed completeness |
Match_Results |
Rule, candidate, amount, residual and reviewer-decision trail | Completed reconciliation |
Exception_Queue |
Unresolved cases, owners and follow-up | Fraud or accounting conclusion |
Source_Register |
Source title, type, date, support and limitation | Completeness of private operational data |
Human_Signoff |
Human acknowledgment of scope and unresolved items | Audit assurance, journal approval or close approval |
This is an illustrative reviewer-ready artifact Treasury Desk AI would prepare. It is not a production reconciliation module.
Synthetic illustrative walkthrough
Synthetic illustrative data — not a real company record.
| Scenario | Invoice-side evidence | Bank-side evidence | Candidate / exception | Human question |
|---|---|---|---|---|
| Clean reference | INV-1001, USD 1,250, open | Booked USD 1,250 credit, reference INV-1001 | Exact candidate | Does payer/entity evidence align? |
| Partial payment | INV-1002, USD 800 | Booked USD 500 credit | Partial-payment exception | How should the residual be handled? |
| One credit, two invoices | INV-1003 USD 300 + INV-1004 USD 200 | One booked USD 500 credit | Grouped candidate | Which allocation rule applies? |
| Fee / short payment | INV-1005, USD 1,000 | USD 970 credit, possible USD 30 fee | Amount exception | Is the gross-to-net path evidenced? |
| Amended invoice | INV-1006 changed after extraction | Credit matches the old total | Stale-snapshot exception | Should the source be rerun? |
| Reversal | Initial credit applied to INV-1007 | Later reversal for the same amount | Reopened match | Should the earlier application unwind? |
These examples illustrate workflow states only. They do not demonstrate model accuracy, time savings, adoption, customer outcomes or production maturity.
What public sources can show
Sequence publicly documents invoice APIs, MCP access to invoice-related data, CSV exports and Watchtower human-review workflows. Its Stripe documentation shows how successful Stripe payment can update an invoice’s paid status, while the Xero integration documentation states that reconciliation in Xero remains a separate step.
The reviewed public sources did not identify an exact Sequence source or permalink for the internally referenced invoice-to-bank comparison workflow.
The complete invoice-to-bank workflow, .xlsx generation and automatic bank reconciliation are therefore not attributed to Sequence.
The Open Banking Transactions standard distinguishes transaction IDs, references, booking dates and value dates. Domestic Payment Consents documents end-to-end identifiers and remittance information, while Domestic Payments distinguishes pending, rejected and settlement-related statuses. Plaid documents a provider-specific pending/posted lifecycle. Swift UETR and the SIX payment glossary support payment-tracking and camt terminology.
These sources cannot decide whether a real bank feed is complete, a real invoice is valid, a candidate should be accepted, a booked credit completes reconciliation, or any accounting, tax, legal, compliance, fraud, audit or period-close conclusion.
AI / human boundary
| AI may prepare | Human must decide |
|---|---|
| Bounded extraction, normalization and schema mapping | Approve source and account scope |
| Approved deterministic rules | Approve rules and mapping versions |
| Candidate suggestions and duplicate-like case surfacing | Resolve ambiguous or identity-sensitive matches |
| Exception grouping and source register | Approve overrides and exception treatment |
| Draft workbook and reviewer memo | Determine accounting and specialist conclusions |
| Reproducible handoff | Reconciliation sign-off and period-close decisions |
Public caveat
This material is a public-source, reviewer-first workflow demonstration using synthetic examples. It is not accounting, tax, legal or compliance advice; audit assurance; fraud certification; bank-feed completeness or payment-finality verification; customer, supplier or beneficiary identity verification; completed bank reconciliation; journal-entry approval; period-close approval; custody, execution or payment initiation. It does not prove accuracy, time savings, adoption, willingness to pay, product-market fit, revenue or traction. A reviewer-ready workbook can organize source evidence, candidate logic and exceptions, but it does not replace controller, treasury, accounting, audit or specialist review.
Primary and contextual sources reviewed
Retrieval date: 2026-07-22.
Sequence
| Source | Type | What it supports | What it does not prove |
|---|---|---|---|
| Sequence MCP | Official changelog | MCP access to invoice-related data | Full invoice-to-bank comparison or reconciliation |
| Watchtower | Official documentation | Human review, approvals and task visibility | Completed reconciliation or audit assurance |
| CSV exports | Official changelog | CSV export of receivables, billing and invoicing data for spreadsheet and ERP workflows | Full invoice-to-bank comparison or completed reconciliation |
| Get an Invoice by ID | Official API documentation | Invoice-object fields and timestamps | Bank posting or cash receipt |
| List all Invoices | Official API documentation | Filters, pagination, limits and API-version metadata | Downstream reconciliation accuracy |
| Stripe integration | Official integration documentation | Stripe payment-link and collection flow; successful Stripe payment can mark the Sequence invoice as paid | Bank posting, bank finality or completed reconciliation |
| Xero integration | Official integration documentation | Payment-status sync and separate Xero reconciliation | Bank-feed completeness or completed reconciliation |
Bank / open-banking
| Source | Type | What it supports | What it does not prove |
|---|---|---|---|
| Capital One Data Access | Official bank/open-banking documentation | Transaction status, account, amount and booking-date fields | Universal behavior across banks |
| OBIE Transactions v3.1.5 | Official standard documentation | Transaction IDs, references, booking and value dates | Feed completeness or completed reconciliation |
| OBIE Domestic Payment Consents | Official standard documentation | Remittance and end-to-end identifiers; consent-state context | Settlement completion |
| OBIE Domestic Payments | Official standard documentation | Payment statuses and expected execution/settlement fields | Booked bank credit or invoice application |
| Nacha ACH Returns Bulletin | Official ACH operations bulletin | ACH return timing and operational context | Universal return behavior across all payment rails |
Aggregator / lifecycle
| Source | Type | What it supports | What it does not prove |
|---|---|---|---|
| Plaid Transactions API | Official provider documentation | Pending/posted lifecycle, links and metadata | Universal bank finality or source completeness |
| Why a Plaid date may differ from a bank statement | Official support documentation | BookingDateTime-versus-ValueDateTime differences for European institutions | Universal behavior across jurisdictions or accounting treatment |
Standards / references
| Source | Type | What it supports | What it does not prove |
|---|---|---|---|
| Swift UETR | Official reference | Payment-chain tracking identifier | Invoice validity or reconciliation decision |
| SIX payment-standardization glossary | Official glossary | camt.052, camt.053 and camt.054 terminology | Availability or behavior at every bank |
Discussion question
What metadata would make an invoice-to-bank review reproducible in your finance workflow?