Cash Reconciliation — User Journey & Pain Points

Seven scenarios — one card for each status a bank transaction can have. Each card answers three questions: what creates this situation (left), what the user does in the tool (middle), and how it resolves and what still needs to happen in Fusion (right).

The tag at the bottom of each card shows the Automation Gap story — once the matching engine is live, can the system write the result back to Fusion on its own, or does a human still need to act in Fusion first?

Concept-fidelity scope. These cards describe the scenarios and Stage 4+ runtime behaviors. Some described behaviors — live matching engine, auto-match-on-arrival, bank-line clustering primitive — are demonstrated in this Concept Build via pre-classified mock data and UI affordances, but their runtime engines are built fresh from spec at Stage 4 Build Alpha. Interactive features in the prototype today: FX Variance JE CSV export, Watching toggle (manual + Matthew Bender auto-watch on ingest), Reconciliation modal, AP loop UI, filter chips, priority tiles. See pain points tab for the per-feature built-vs-demonstrated breakdown.

System can write result back to Fusion automatically (Automation Gap)

Human must act in Fusion first — then system can write back

No write-back needed — Fusion already handled it

Auto-Reconciled

Fusion matched this transaction automatically — no user action required

Informational only. POC surfaces it for audit visibility.

Detection

Fusion's reconciliation engine found an exact reference match before the item reached the manual queue. POC reads the reconciled status from the Fusion export.

Wire / EFTEnd-to-End ID → Payment Ref No. confirmed

CheckCheck No. → Transaction No. confirmed

Direct DebitAuto-Reconciled not applicable — manual journal entries; Fusion cannot auto-match

User journey

Sees transaction in list with green Auto-Reconciled badge

Clicks row to open read-only panel — verifies matched GL entry, date, amount

No action taken — Fusion already completed this reconciliation

Exception Intelligence outcome

In the transaction list, auto-reconciled items appear with a green "Auto-Reconciled" badge. Clicking any one opens a read-only detail panel — bank statement line on the left, matched GL entry on the right, with a green confirmation: "Auto-reconciled with high confidence by Fusion reconciliation engine. No action required." No reconcile button is shown. The value is spot-check visibility: the cash management team can review any auto-reconciled item in the same interface where they work exceptions, without navigating to a separate view in Fusion.

Fusion

Already reconciled. Nothing to write back.

N/A — Fusion handled it

Exception Intelligence value case — confirm with cash management team

Steps this replaces

None — Fusion already reconciled before the queue loaded. Exception Intelligence adds spot-check visibility in the same interface; no separate Fusion navigation required.

Quantify

• How many items auto-reconcile per day? (Denominator for exception rate; Smart Intelligence training baseline.)

Unmatched

No GL entry found for this bank line

User locates the GL entry manually and confirms the match in the POC

Detection

Fusion's engine could not connect the bank line to any GL entry — typically a reference format inconsistency (leading zeros stripped, whitespace mismatch) or a GL entry that hasn't been posted yet.

Wire / EFTEnd-to-End ID → Payment Ref No.

CheckCheck No. → Transaction No.

Direct DebitEnd-to-End ID → ? unconfirmed

SweepNo single ID — batch balance to $0.00

User journey

Sees bank transaction with "no match found" state. POC shows closest GL candidate if one exists — highlighted for review.

Verifies the candidate, selects it, and clicks Reconcile. (If no GL entry exists, creates one in Fusion first, then returns.)

POC records Manually Reconciled with timestamp, bank line ID, and matched GL entry ID

Exception Intelligence outcome

Opening an Unmatched transaction shows the reconciliation modal with the alert: "Fusion could not auto-reconcile this transaction. The likely GL candidate is highlighted — verify the identifier matches and the amount is correct, then click Reconcile. If no candidate matches, click Flag for Investigation." The GL candidates table shows the probable match marked with a "✓ match" pill; the key identifier column is highlighted in blue for quick comparison. Once the correct entry is selected and amounts align, the Reconcile button activates. The tool records the confirmed match with a timestamp, the bank line ID, and the GL entry ID. If no GL entry exists, Flag for Investigation holds it in a visible queue until one is created in Fusion.

Fusion

A true Unmatched item means no GL entry exists — Automation Gap cannot write back a match that doesn't exist. The GL entry must be created in Fusion first. Items that appear Unmatched due to reference format issues are caught by the EI Engine before reaching this point — they reconcile as EI Engine-Reconciled.

Human step required — GL entry must exist in Fusion first

Exception Intelligence value case — confirm with cash management team

Steps this replaces

Manual GL search in Fusion — hunting for a matching entry without a highlighted candidate. Exception Intelligence surfaces the likely match and highlights it; user verifies rather than searches.

Quantify

• How many unmatched items land per day?

• How long does a manual GL search take per item today?

EI Engine-Reconciled

EI Engine matched a bank line to a GL entry that Fusion could not auto-confirm

Reference format mismatch (leading zero, whitespace, day-mismatch) — the EI Engine matched on end-to-end ID + amount after string normalization. Exception Intelligence: informational read-only panel. Automation Gap: these reconcile automatically and write back to Fusion.

Detection

Fusion's auto-reconciliation failed because of formatting differences (leading zeros on the bank side that Fusion can't normalize, day-based matching that doesn't account for clearing lag, or — for wires — Fusion grabbing unrelated transactions and being turned off entirely by the team). The EI Engine applies the rule Fusion can't: end-to-end ID + amount, with string normalization.

The matched GL entry is shown in a read-only panel. In Exception Intelligence, the user sees what the engine found — reconciliation itself still happens in Fusion. Automation Gap eliminates the Fusion step.

User journey

Sees transaction in list with the ⚙ EI Engine-Reconciled badge — the engine has already identified the GL match

Clicks to open read-only panel — reviews the matched GL entry and the blue alert naming the specific reference the engine matched on

No action taken in the tool — reconciliation still happens in Fusion for Exception Intelligence; Automation Gap eliminates this step entirely

Exception Intelligence outcome

In Exception Intelligence, EI Engine-Reconciled is informational only. Clicking the transaction opens a read-only panel — the same layout as Fusion-Reconciled — showing the bank entry and the matched GL entry side by side. A blue alert reads: "EI Engine matched this on end-to-end ID + amount after string normalization. GL entry: [ref]. Automation Gap (Beta / Stage 7) reconciles these automatically and writes the match back to Fusion." There is no Reconcile button. Reconciliation still happens in Fusion. The value in Exception Intelligence is visibility: the engine has identified the match and named the specific GL entry. In Automation Gap, these items disappear from the manual queue entirely — the engine writes the confirmed match to Fusion via the Manual Reconciliation Service API without any human step.

Fusion

Automation Gap: POC writes confirmed match back to Fusion via reconciliation API. Same mechanism as Unmatched — clean 1-to-1 write-back.

Automation Gap — automatable write-back

Exception Intelligence value case — confirm with cash management team

Steps this replaces

None in Exception Intelligence — read-only informational panel; reconciliation still done in Fusion. Exception Intelligence value is visibility only: the engine has already found the match.

Quantify (Automation Gap key metric)

• How many items per day have reference format mismatches that Fusion misses? This is the headline Automation Gap volume figure — these disappear from the manual queue in Automation Gap.

Returned Payment

Payment was sent and returned by the bank — bank-line-vs-bank-line reconciliation

Original outflow + later return inflow are two separate bank rows that belong together. Often less bank charges. No system-side row is created — AP needs the original `negotiable` to stay open for reissue.

Detection

Bank statement shows the original payment leaving and a corresponding return inflow (sometimes net of a bank charge — JPMorgan or beneficiary bank, varies). Per spec §7.2.1: reconciliation is bank-line-vs-bank-line only.

Wire / EFTBeneficiary bank unreachable; ACH return code

CheckNSF; account closed at receiving bank; stop payment placed

Direct DebitReturned Payment scenario unconfirmed for DD — validate with cash management team unconfirmed

User journey

Sees Returned Payment alert. Both bank lines (original + return) are visible together via the bank-line clustering primitive (per spec §9). GL candidates panel shows empty-state — no system-side row by definition.

In Fusion: if original already reconciled → unreconcile it → reconcile original + return together as two bank items. If aware of return before original was reconciled → reconcile both directly. AP team handles reissuance separately.

Tool marks as Manually Reconciled with timestamp + cluster ID. AP escalation flagged via the structured AP loop — "Escalate to AP" with the AP response options (Resolved in Fusion / Reference info / Researching further).

Exception Intelligence outcome

Opening a Returned Payment item shows the reconciliation modal with a red alert and the cluster of bank-side rows that belong together. The GL candidates panel shows the spec-§9 empty-state explaining bank-line-vs-bank-line reconciliation rather than implying a missing GL entry. AP escalation is tracked via the structured AP loop. Speed of reconciliation matters here — see Pain Point 11 (AP void risk): the faster cash mgmt clears returned items, the shorter the window where AP sees stale `negotiable` status and can void+reissue, causing double-pay.

Fusion

AP team handles reissuance in Fusion — payments workflow, not reconciliation. Reconciliation follows after the replacement payment clears the bank.

Human step required — AP handles reissuance in Fusion

Exception Intelligence value case — confirm with cash management team

Steps this replaces

Manual AP notification (Teams message or email) + manual tracking of the original ↔ return relationship. Exception Intelligence clusters them together visually and makes the handoff a tracked, timestamped escalation under the AP Escalations filter — cannot be missed or forgotten.

Quantify

• How many returned payments occur per week?

• Has one ever been caught late — and what was the impact (e.g., AP voided + reissued causing double-pay)?

Duplicate Partial Refund

Two bank lines for one GL entry, with partial credit applied forward and remainder refunded

AP voided in Fusion but original cleared the bank, then AP reissued — two bank lines for one GL line. Partial credit applied to a future invoice + remainder refunded as a separate bank-side correction row. Source: Joanne Parris, May 8 2026.

Detection

Two bank-side rows tied to one GL entry: original payment + reissued payment + a refund line whose amount doesn't match the original (because part was credited forward). Distinct from Returned Payment in that the refund math is original − credit-applied-forward, not original − bank charges. Carries Amount Variance descriptor.

⚠ Detection signals open (spec §12 Q5a): mechanism is known, detection approach is not. When Allison spots one in her queue today — what signals does she use? Vendor + amount + date proximity? Specific Remarks fields? A refund line that doesn't match any other payment's amount? Awaiting Allison response.

User journey

Sees Duplicate Partial Refund cluster — multiple bank-side rows linked to one GL entry via the bank-line clustering primitive (per spec §9). Amount Variance descriptor surfaces because original ≠ refund.

Reviews the cluster, identifies the credit-forward + refund math, escalates to AP/GL team via the structured AP loop if a reversal is needed.

Once GL team resolves (if needed) and the cluster math nets correctly, user returns to reconcile. Cluster ID + audit trail recorded.

Exception Intelligence outcome

Opening a Duplicate Partial Refund item shows the bank-line cluster — the original payment, the reissued payment, and the refund line — all linked to the single GL entry. The alert names the credit-forward + remainder math. Exception Intelligence gives Allison the structured cluster view she doesn't have today. AP escalation tracked through the AP loop. Detection signals (Q5a) need confirmation before this surfaces automatically; for now, manual flagging with cluster grouping support.

Fusion

If a GL reversal is needed, AP/GL team handles it in Fusion. Reconciliation follows. GL reversal cannot be automated through the reconciliation API.

Human step possible — GL reversal in Fusion if needed

Exception Intelligence value case — confirm with cash management team

Steps this replaces

Manual mental tracking of the original ↔ reissue ↔ refund relationship across multiple bank statement lines. Exception Intelligence clusters them via bank-line linkage, surfaces the credit-forward + remainder math, holds the cluster under a dedicated filter.

Quantify

• How many Duplicate Partial Refunds occur per week/month?

• How are these tracked today? (Q5a — Allison detection signals)

FX Pending JE

FX wire (514) — bank-side and system-side amounts differ; manual journal entry required for the FX delta

Always carries Amount Variance descriptor by definition. Cannot auto-reconcile until cash management posts the variance JE; once it flows to the system side, the entry can be matched (manually or by EI Engine).

Detection

Bank amount (foreign currency, settled in USD by the bank) differs from GL amount (USD originally booked). Expected for FX wires — the conversion rate at bank settlement differs from the rate booked in the GL.

Wire 514 (FX)FX Pending JE applies until the variance JE posts

Wire 495 (USD)USD amounts must match exactly — no Amount Variance descriptor

EFT / CheckAmount fixed at issuance — no Amount Variance descriptor

Direct DebitDD Pending status applies separately when AP ledger entry hasn't posted

User journey

Sees FX wire with FX Pending JE status. Priority tile surfaces all FX Pending JE items together with a "⤓ Generate JE CSV" action.

Clicks Generate JE CSV — exports a journal-entry-ready CSV: one cash line per wire (Debit or Credit per variance) plus a single netted FX Gain/Loss offset line, account strings pre-populated. User pastes into Fusion's journal upload template, adds the FX wires to the Watching list, and submits.

Once the journal posts and the matching system-side entry appears, the prototype auto-matches on end-to-end ID + amount, retiring items from Watching. Tool records Manually Reconciled with timestamp + cluster ID.

Exception Intelligence outcome

The tool holds FX wires in FX Pending JE state from bank-statement-receipt until the next weekly variance JE posts. The CSV export collapses Allison's multi-step Excel workaround (~200 FX wires/month, hour+ per batch day; "click click click copy paste upload — no value add") into a one-click action with the JE structure already built. Watching list integration auto-matches once system-side appears. Nothing falls through between bank date and the next variance JE.

Fusion

Variance JE creation happens in Fusion (manual, weekly step with month-end-close handling for late-month wires) — Beta (Stage 7) staging includes v2 (populate Fusion's journal upload template directly — the template is an Excel form with a submit button that hands off to Fusion) and Phase 2+ (API write-back of the FX delta JE directly via Fusion REST API).

Human step today — JE creation in Fusion; auto-match on end-to-end ID once posted

Exception Intelligence value case — confirm with cash management team

Steps this replaces

Manual per-wire workflow: pull bank line + matching GL entry, compute variance, decide debit vs. credit by sign, format into Oracle's journal-upload Excel template, upload, then come back to look up + match each FX wire one by one. The CSV export + Watching auto-match collapses this into "filter, export, journal, watch."

Quantify

• ~200 FX wires per month (Allison soft estimate, May 8 2026 — illustrative pending Bobby's data).

• Big-batch day costs an hour or more (Allison soft estimate).

Sweep (ZBA Batch)

Multiple bank entries matched to multiple journal entries — must balance to $0.00

Transaction codes: 275 (standard sweep) · 575 (negative — handling unconfirmed)

Detection

No single identifier links bank to GL. Multiple ZBA sweep entries on both sides must sum to the same total. Reconciliation completes when the running difference = $0.00.

Code 575 entries (negative amounts) are excluded from the default batch selection and shown as inactive. Their handling has not been confirmed with the cash management team.

Open: What does code 575 mean, and are those entries reconciled separately or skipped entirely?

User journey

Opens sweep batch view — two panels showing bank entries (left) and journal entries (right) with running totals. Code 575 entries shown but inactive.

Selects entries on both sides until the difference reaches exactly $0.00, then clicks Reconcile

All selected entries marked Manually Reconciled simultaneously with timestamp and batch IDs

Exception Intelligence outcome

When the running totals on both sides reach exactly $0.00, the Reconcile button activates and the user clicks once. The tool simultaneously closes all selected bank entries and journal entries as Manually Reconciled, records the batch as a single event with a timestamp, and removes them from the open queue. The $0.00 balance is the confirmation — if the two sides don't balance, the batch isn't complete and the button stays locked.

Fusion

Automation Gap: POC writes all matched pairs back to Fusion as a batch operation. More complex than 1-to-1 write-back but same API mechanism — multiple bank line IDs paired with multiple GL entry IDs.

Automation Gap — batch write-back (more complex than 1-to-1)

Exception Intelligence value case — confirm with cash management team

Steps this replaces

Manual summation of bank and journal entries to verify $0.00 balance. Exception Intelligence calculates running totals automatically and locks the Reconcile button until the balance is exact — no mental arithmetic required.

Quantify

• How many entries are in a typical daily sweep batch?

• How long does the manual balance verification take today?

Each feature in this prototype traces directly to something said in discovery. No invented problems, no assumed workflows. Direct quotes from three sessions (April 27–30 2026) are mapped to the prototype capabilities built in response.

Pain points · quotes · prototype response

Pain Point	Direct Quotes	What We Built
1 Payment failures went undetected — suppliers called before the team knew When Fusion's bank file was loaded but reconciliation lagged, failed payments were invisible. The only signal was a vendor calling to ask where their money was — days after the payment had already failed.	We weren't reconciling as probably quickly as we should have. And so you could think you made a payment to a supplier because the payment looks like it left Fusion. A week could go by and if you haven't done the bank reconciliation to learn, oh, well actually the payment didn't go out. Now the supplier's unhappy. They're like, where's our money? We've got to go back. Cash management team · Apr 2026 I run an exception file for the disbursement account through JP Morgan... I'll get an exceptions report. And a lot of times it's usually a day or two later. So it's not as on time, I guess. Cash management team · Apr 2026	In prototype built Returned Payment status + priority tile surface these immediately in the main queue. This is the core Exception Intelligence premise — exceptions surface the moment the bank file is loaded. The team doesn't discover a problem by working through a queue; it surfaces immediately, classified by reason (Returned Payment / FX Pending JE / DD Pending / Duplicate Partial Refund / Other Unmatched). No more relying on a vendor call or a day-late exceptions report to know a payment was returned.
2 Escalation tracking lives in email, not in the tool When something gets sent to AP, the only record is in a sent folder. Following up means hunting through old email threads to reconstruct what was asked and when.	I go back and I'm like, oh yeah, what happened with this item? And then I go in my emails and find wherever like I last talked about it and see if I can pick up the thread. Cash management team · Apr 2026 If I have a bank item that I'm questioning, I will take a screenshot of the bank statement or the screen in Fusion... and send that over to the AP help desk, usually copying Emmy and another person. Cash management team · Apr 2026	In prototype built "Sent to AP" flag on each transaction. Set from inside the reconciliation modal after she's decided to escalate. Records the date she sent it (required — calendar picker). The transaction stays marked until she closes it out — no more reconstructing from email.
3 No single view of what's waiting on AP There's no way to filter to only the items pending AP response. Escalations go into what she called "the void."	It's usually just send it into the void of AP and wait and see if they ever come back with an answer. Cash management team · Apr 2026 I do everything that I can. And then when I have a day where I don't have much going on and I start looking into the statement again, I go back and I'm like, oh yeah, what happened with this item? And then I go in my emails and find wherever like I last talked about it and see if I can pick up the thread of, hey, is there an update on this yet? And then wait again. Cash management team · Apr 2026	In prototype built "Sent to AP" filter in the transaction list. One click to see every open escalation with her notes attached. No scrolling, no email hunting. CSV export of filtered view — date, type, amount, description, notes, sent date — for AP manager meetings.
4 Items sent to AP sit unanswered for months — no way to surface them With no persistent tracking, escalated items can disappear into the AP inbox indefinitely. There are 12 wires with non-standard reference IDs that have been open since July 2025 — sent to AP, never resolved.	From July till now, I've got like 12 wires that have different bank reference IDs — the end-to-end ID — than what the normal wires have, so I don't know what they are and I can't find them in the system transactions, so I send that to AP... they're still out here because I probably haven't heard anything back from AP about what they are. Cash management team · Apr 2026 I follow up with AP so much and I feel like I never get an answer. So I don't feel like I have a lot of examples of what they've come back with because it's usually just send it into the void of AP and wait. Cash management team · Apr 2026	In prototype built "Sent to AP" and "Watching" states persist until explicitly closed. The date picker records when she sent — aging becomes visible at a glance. The filter makes every open item reviewable in one view. Nothing can fall through if it's been assigned a state.
5 Context disappears between seeing an item and acting on it When a transaction needs investigation, there's nowhere to capture what she knows in the moment. By the time she comes back — or is ready to email AP — the context is gone.	If it's something that's requiring more investigation, like on my side, whether that's looking into things here or reaching out to AP, having that notes column would be real helpful... put some notes in and then you haven't yet emailed AP and so you want to be able to like come back maybe and then craft your email. Cash management team · Apr 2026 A comment of like flagging something, even if it's just me knowing like, I've sent this item for investigation or I've looked into this and I can't figure it out or whatever. That would be really helpful. Cash management team · Apr 2026	In prototype built Per-transaction notes field inside the reconciliation modal. Free-text, saves to the transaction. Available whether she's about to email AP, mid-investigation, or leaving herself a breadcrumb.
6 No way to deliberately hold an item she's watching Sometimes she recognizes an item and knows it will likely resolve itself — a timing issue, an expected journal arriving soon. She needs to flag it without escalating and come back when ready.	Sometimes it's just a timing thing and I know, oh, I know what this is. Something's probably coming. I'm going to hold this. Cash management team · Apr 2026 I do everything that I can. And then when I have a day where I don't have much going on and I start looking into the statement again, I go back and I'm like, oh yeah, what happened with this item? Cash management team · Apr 2026	In prototype built "Watching" state — a deliberate hold flag, separate from "Sent to AP." She's not waiting on anyone; she's watching. Paired with the notes field. Can transition to "Sent to AP" or close directly to reconciled — no dead end.
7 Fusion collapses data — key fields require opening each transaction Fusion's row view doesn't show enough to identify a transaction's type or routing. She maintains a parallel Excel file specifically to see fields Fusion hides by default.	It's also just faster for me to have two screens open basically and be able to see everything on here and I can just expand my files and see all the columns that I need without having to open each transaction to be like, I can see this is a credit card, but which credit card? And then to open it, wait for it to load, find the name, close it. Cash management team · Apr 2026 Being able to see that Remarks 9 column confirms that it's a direct debit and tells me which credit card that belongs to. So then I know what next steps are needed. Cash management team · Apr 2026	In prototype built Reconciliation modal surfaces key fields directly — Remarks 9, transaction type, counterparty, and matching identifier visible without navigating Fusion. Human-readable type labels replace raw codes. No parallel Excel needed to identify what a transaction is.
8 A custom Excel workaround fills the gaps Fusion leaves — and gets maintained every day Because Fusion's transaction codes are opaque and the import can't be verified, the team built and maintains a private Excel file with formulas that translate codes into human-readable types, categorize transactions, and run a sanity check that the bank file loaded completely. It's a daily parallel system that exists to fill Fusion's gaps.	I still pull up the bank statement and I pop it into my Excel. I have a formula that identifies the type of transaction that it is. So between EFT check, a return, the cash sweeps, wires, all that kind of stuff, it automatically does that with a formula. That just helps me visualize it because that's how I did it for so long. Cash management team · Apr 2026 The way that they're named in Fusion, it's a much more rigid system. I can't decide what that transaction name is. Having three different electric funds transfers, transaction code names, doesn't necessarily tell me that that's an EFT versus a wire. Cash management team · Apr 2026	In prototype built Human-readable transaction type labels replace Fusion's raw codes — "Wire," "EFT," "Direct Debit," "Check," "Sweep." The reconciliation modal surfaces type, remarks, and key fields without any translation step. Her Excel file was a workaround for information that should be visible in the tool.
9 FX wire variance journals: a multi-step Excel workaround for every wire Every foreign-currency wire requires its own journal-entry workflow. She pulls the bank line and the matching system entry, computes the variance, decides debit vs. credit by sign, formats the data into Oracle's journal-upload Excel template, uploads, then waits for the entry to populate back in system transactions, then comes back to look up and match each FX wire one by one. ~200 FX wires per month. No part of the work is judgment-driven.	It is literally just click click click copy paste upload — there's no value add in the work I'm doing at that point. I'm literally just clicking buttons telling it to match things. Nothing I'm doing is a value add right there. Cash management team · May 2026 I have to do the journal, put it into the system, wait for them to populate into system transactions, and then look them up one by one. Match them one by one, all the way, for all 200 of those. Cash management team · May 2026	In prototype built FX Variance JE CSV export — one-click action on the FX Pending JE priority tile produces a journal-entry-ready CSV: one cash line per wire (Debit or Credit per variance) plus a single netted FX Gain/Loss offset line, account strings pre-populated. Drops directly into Fusion's journal upload template. Interactive — real code, runs on click. Watching list (manual flag) — user can toggle an FX wire to Watching after journaling. Interactive — toggle works and persists. Demonstrated as concept fidelity runtime engine lands at Stage 4 Auto-match on end-to-end ID once system-side row appears — the prototype shows the post-match outcome (rows pre-classified in mock data) but doesn't run a live matching engine against changing data. The runtime trigger is built at Stage 4 Build Alpha when real bank + Fusion CM data flows in and the matching engine (§6/§9 of spec) is implemented. Staged for later pending v2: populate Fusion's journal upload template directly — the template is an Excel form with a submit button that hands off to Fusion, eliminating the intermediate copy-paste step. Phase 2+: API write-back of the FX delta JE directly, eliminating the upload step entirely.
10 Fusion's auto-reconciliation can't handle the routine work — so all of it stays manual Fusion has an auto-reconciliation feature, but it doesn't work for the team's most common transaction types. For wires, Fusion grabs unrelated transactions — the team turned it off entirely. For checks, Fusion can't normalize leading zeros on the bank side and tries to match on day, neither of which is reliable. For EFTs, JPMorgan batches them in a way that's incompatible with how Fusion stores individual lines, and Fusion only matches on amount + date today. Result: every USD wire, check, and EFT is reconciled by hand, every day — work that should be 100% automated.	The most tedious ones are going to be the FX, the checks, and the wires, because those all should have the ability to be auto-reconciled with the information that we have. And it's just Fusion can't do it right now. Cash management team · May 2026 When we run that [auto-reconciliation] process in Fusion, it can mostly capture the wires and do those really great. The problem was that it was grabbing extra stuff that it wasn't supposed to be touching. And it was reconciling it. So we stopped using it because it was just causing more problems. Cash management team · May 2026 (on wires) The reason Fusion couldn't do it is because it populates leading zeros on the bank side and it couldn't do both. It also tries to match on day, and it can't do that. Cash management team · May 2026 (on checks)	Demonstrated as concept fidelity runtime engine lands at Stage 4 EI Engine auto-match — concept fidelity. The prototype shows the post-match outcome by pre-classifying mock data with EI Engine-Reconciled status and the matching modal alerts. The matching engine itself doesn't exist as code yet — it lives in spec §6 (Matching Logic), §7 (Match Status Reasons), §8 (Validation), and §9 (Architectural Decisions). Stage 4 Build Alpha is where the engine is built fresh from spec and run against real bank + Fusion data; only then will USD wires, checks, and EFTs actually disappear from the manual queue. In prototype built Reconciled view with match-source attribution (UI built) — every reconciled row carries one of three badges: ✓ Fusion-Reconciled, ⚙ EI Engine-Reconciled, or ✎ Manually Reconciled. The badges are interactive (filter by source). The badge values themselves come from pre-classified mock data in this Concept Build; once the EI Engine runs at Stage 4, badges will be assigned by the engine. Staged for later pending Beta (Stage 7): write-back to Fusion via the Manual Reconciliation Service API so EI Engine matches persist back to Fusion as the system of record.
11 Matthew Bender checks: bank rows appear weeks before the matching system-side entry exists Matthew Bender (a LexisNexis-owned company that uses RELX's bank account) issues checks throughout the month. The bank-side rows can appear any time. But the matching system-side entry is a manual journal entry posted only at month-end. So bank lines sit visible for weeks with no system counterpart to match against — and there's no clean place to put them in the meantime.	Bank-side rows can appear any time during the month; system-side rows appear only at month-end. Cash management team · May 2026	In prototype built Auto-watch on data ingest — at load, the prototype recognizes Matthew Bender bank rows (vendor pattern + 8-digit padded check number) and auto-tags them to the Watching list with status "Other Unmatched" and GL status "Pending — Month-end JE." The "⚙ Auto-watched" badge distinguishes auto-tagged rows from user-flagged "Watching." Interactive — runs on data load; observable in the prototype today. Demonstrated as concept fidelity runtime engine lands at Stage 4 Auto-match on month-end JE arrival — the prototype shows the post-match outcome (rows pre-classified once paired) but doesn't run a live matching engine against changing data. The runtime trigger — detect new GL row + auto-match on Transaction Number + amount — is built at Stage 4 Build Alpha when real bank + Fusion data flows in and the matching engine (§6/§9 of spec) is implemented.
12 AP voids payments showing as "negotiable" — even after the money has left the bank When AP tells the bank to pay, the item appears in AP's view as "negotiable." It only flips to "cleared" once cash management reconciles. Until then, AP can void a "negotiable" payment without consulting cash management — even if the money has already left the bank. If a vendor calls AP saying "I haven't been paid," AP sees "negotiable," voids and reissues, and the company double-pays.	AP is like, oh, okay. It says negotiable. Click void and reissue. And then we will double pay because the first one actually did go through, but AP doesn't know it yet. Cash management team · May 2026	In progress pending This prototype cannot directly prevent the void. System-enforced void prevention lives in AP's Fusion workflow, not in cash management's tooling. Full void prevention is out of scope. Indirect mitigation: speed of reconciliation. The faster routine items are reconciled, the shorter the window where AP sees stale "negotiable" status. By auto-matching wires, checks, EFTs, and FX wires (via the EI Engine + FX JE export), the prototype frees the team to clear bank items same-day rather than days later — collapsing the void-risk window. Whether this materially reduces double-pay incidents depends on how AP's process changes alongside cash mgmt's faster cadence — pending validation.

Built — live in the prototype today

In progress — designed, being built

All quotes · Cash management team · Apr 27–30 2026