Cash Reconciliation — Workflow Overview

→

Wire Transfer

Transaction codes: 495 (USD) · 514 (FX / foreign currency)

How matching works

End-to-End ID

bank side

Payment Reference Number

GL side

confirmed

String comparison. Both fields must match exactly, including leading zeros.

USD wire (495)

Amounts match exactly. Bank-side End-to-End ID maps directly to GL-side Payment Reference Number. Should auto-match every time via the EI Engine on end-to-end ID + amount — but Fusion's auto-reconciliation grabs unrelated transactions, so the team turned it off entirely. The EI Engine fills that gap. Per Allison: "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."

FX wire (514) — multi-step Excel workaround today

~200 FX wires per month. Bank amount is in foreign currency; GL amount is the USD equivalent. Amounts will not match. Allison currently does this entire workflow by hand for every wire: pull bank line + matching system entry, compute variance, decide debit vs. credit by sign, format into Oracle's journal-upload Excel template, upload, then come back to look up and match each FX wire one by one. One big-batch day costs an hour or more. Per Allison: "It is literally just click click click copy paste upload — there's no value add in the work I'm doing at that point." confirmed May 8 2026

Possible reasons for unmatched (per spec §7)

Returned Payment FX Pending JE Other Unmatched

FX Pending JE applies to 514 FX wires until the next weekly variance journal entry posts. Amount Variance is a cross-cutting descriptor (always present on FX wires, never on USD wires per spec §8).

What's interactive in the Stage 3 Concept Build today: 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. Watching list (manual flag) — user toggles an FX wire to Watching after journaling.

Demonstrated as concept fidelity (runtime lands at Stage 4): auto-match on end-to-end ID once the system-side row appears — the prototype shows the post-match outcome via pre-classified mock data, but doesn't run a live matching engine against changing data. The matching engine (§6/§9 of spec) is built fresh from spec at Stage 4 Build Alpha when real bank + Fusion data flows in.

Beta (Stage 7) staging: v2 — populate Fusion's journal upload template directly. The template is an Excel form with a submit button that hands off to Fusion; v2 collapses the intermediate copy-paste step. Phase 2+ — API write-back of the FX delta JE directly via Fusion REST API, eliminating the upload step entirely. Conceptually distinct from the broader reconciliation match-record write-back (Manual Reconciliation Service API); both happen via Fusion API but are independent capabilities scoped separately.

#

Check

Standard checks and Matthew Bender checks (different matching fields — see below)

How matching works

Check Number

bank side

Reference / Transaction Number (same value)

GL side

confirmed

Direct 1-to-1 lookup. Check number is a string — leading zeros must be preserved in both fields for the match to work.

Standard checks — workflow

Check clears the bank. System matches check number on bank side to Transaction Number in GL. EI Engine auto-matches on Transaction Number + amount. Fusion's own auto-reconciliation fails on checks 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" (Allison, May 8 2026). The EI Engine's string normalization (preserving leading zeros) closes that gap.

Matthew Bender checks — bank rows arrive weeks before system-side entry

Matthew Bender is a LexisNexis-owned company that uses RELX's bank account to pay vendors. Bank-side rows can appear any time during the month; the matching system-side journal entry is posted only at month-end. So bank lines sit visible for weeks with no system counterpart to match against.

Distinguished from regular checks by check number length: regular checks ≈ 4 digits; Matthew Bender ≈ 8 digits with leading-zero padding. Match basis once system-side appears: check number in Transaction Number AND Journal Line Description in Fusion (both fields contain the check number, vs. standard checks where it's Transaction Number only). confirmed May 5 2026

Possible reasons for unmatched (per spec §7)

Returned Payment Duplicate Partial Refund Other Unmatched

Checks do not carry Amount Variance — check amount is fixed at issuance (confirmed May 8). Matthew Bender bank-side rows pre-month-end land as Other Unmatched + Auto-watched.

What's interactive in the Stage 3 Concept Build today: Matthew Bender auto-watch on data ingest — at load, the prototype recognizes Matthew Bender bank rows (8-digit padded check number + vendor pattern) and auto-tags them to the Watching list with status "Other Unmatched" and GL status "Pending — Month-end JE." Distinguished in the UI as "⚙ Auto-watched" (vs. user-flagged "Watching"). Empty-state in the GL candidates panel explains the month-end-JE timing rather than implying the GL entry is missing. Real code, runs on data load; observable in the prototype today.

Demonstrated as concept fidelity (runtime lands at Stage 4): EI Engine auto-match for standard checks on check number + amount — the prototype shows the post-match outcome via pre-classified mock data; the matching engine itself (§6/§9 of spec) is built fresh from spec at Stage 4. Auto-match on month-end JE arrival — same concept-fidelity caveat; the runtime trigger lands at Stage 4 when live data flows in.

Beta (Stage 7): Matthew Bender auto-match writes back to Fusion via Manual Reconciliation Service API once the month-end JE posts, retiring the bank rows from the Watching list without user intervention.

≈

EFT (Electronic Funds Transfer)

ACH-based payments · code 466 (batch/settlement, reconciliation level) · code 168 (returns, manual workflow) · code 475 reclassified to Check as of mid-August 2025

How matching works

End-to-End ID + amount

bank side

Payment Reference Number + amount

GL side

confirmed May 8 2026 (post-JPM-fix)

Same rule as Wires and Checks. Today, JPMorgan delivers EFTs in a batched format on the bank statement that doesn't align with how Fusion stores individual EFT lines. Bobby Fanelli is driving the JPM unbatch coordination — once delivered as 1:1 line items, EFT matching collapses to end-to-end ID + amount. The system is built under that assumption (carve-out per spec §9).

Normal workflow

Code 466 entries (DEBIT ACH SETTLEMENT) — once 1:1 line-item delivery lands, EI Engine auto-matches on end-to-end ID + amount.

Code 168 entries (EFT returns) — manual unreconcile/reconcile in Fusion: unreconcile original, then reconcile original + return together. Out of scope for v1 auto-match.

Code 475 — was historically EFT (Risk team), reclassified to Check in mid-August 2025. Not an EFT.

Possible reasons for unmatched (per spec §7)

Returned Payment Duplicate Partial Refund Other Unmatched

JPM unbatch coordination in progress (Bobby Fanelli): JPM confirmed they can switch EFT delivery from batch to line-item with 1–2 days' turnaround. Joanne flagged a sandbox-test gate before pushing to production — Fusion's current auto-reconciliation matches on amount + date only, so sending line-item data without a Fusion-side change could break reconciliation worse. Fix the data issue + change Fusion's matching key in parallel.

Demonstrated as concept fidelity in the Stage 3 Concept Build (runtime lands at Stage 4): EI Engine auto-match for EFTs uses end-to-end ID + amount — the same rule as Wires and Checks (per spec §9 EFT carve-out). The prototype shows the post-match outcome via pre-classified mock data; the matching engine itself (§6/§9 of spec) doesn't yet exist as code and is built at Stage 4 Build Alpha when live data + JPM line-item delivery are in place. Beta (Stage 7): write-back via Manual Reconciliation Service API closes the loop for code 466 EFTs. Code 168 returns remain manual (separate workflow design needed).

←

Direct Debit

Three distinct sub-types sharing transaction code 455 — PA Supreme Court (DD) · Citibank Credit Card (CC) · RELX CENTRE CTA US (IC Entry)

PA Supreme Court — match basis

N:1 subset-sum (many bank lines → one Payables entry)

Counterparty = SUPREME COURT OF PA on GL side

confirmed May 12 2026

Bank-side P460 lines (Customer Reference, transaction code 455) accumulate over weeks. Kathy Courson emails AP to batch them; AP creates one consolidated Payables entry. The match: find the subset of bank lines whose amounts sum to the Payables amount. Counterparty filter on GL side is reliable (should not appear on any other transaction type). Source: Allison's P460 Matching.xlsx 2026-05-12 — Group 7095 example shows 8 bank lines totaling $1,557 → 1 Payables entry $1,557.

Citibank Credit Card (CC)

Identified via Remarks 9 / IND NAME — the only distinguishing field. ORIG CO NAME = "CITIBANK, N.A." for all 7 CC entries; cannot distinguish individual CCs by ORIG CO NAME. confirmed May 8 2026

7 CCs currently paid through the account. GL process (journal entry vs. AP payment) — Joanne flagged that AP setup with both DD and EFT method has caused double-pay incidents at Citibank.

RELX CENTRE CTA US (IC Entry)

Confirmed IC journal — LN pays on behalf of Corporate RELX; Corporate RELX reimburses LN. Not an external vendor payment. GL path is different from DD and CC. confirmed May 5 2026

Possible reasons for unmatched (per spec §7)

DD Pending Other Unmatched

DD Pending = bank-side withdrawal occurred but the AP ledger entry hasn't posted yet. Resolves automatically once the AP entry posts.

Architectural commitment (per spec §9): DD matching rules are subtype-keyed, not type-keyed. A single "Direct Debit" rule is not viable — at minimum each subtype within JPM has its own match basis. Rule registry must support bank+subtype keys (PA Supreme Court / Citibank CC / RELX CENTRE CTA US, each with its own rule). Adding a new DD subtype = adding a new rule entry. Beta (Stage 7): CC classification requires an IND NAME lookup table for all 7 card variants; IC Entry needs its own code path. DD subtypes deferred from EI Engine auto-match; manual reconciliation remains the workflow.

↕

Sweep (ZBA)

Transaction codes: 275 (standard sweep) · 575 (bank timing entry — included in batch same as regular entries)

How matching works

Many-to-many batch reconciliation. Multiple bank statement lines are matched against multiple journal entries. The two sides must sum to the same total — reconciliation completes when the difference is $0.00.

No single identifier links bank to GL — balance is the confirmation.

Normal workflow

ZBA sweep moves money between LexisNexis accounts daily. The user selects the relevant bank entries and journal entries, verifies both sides balance to zero, then reconciles as a batch. Code 575 entries are included in the batch — they occur sometimes and are related to bank timing; handled the same as regular sweep entries. confirmed May 2026

Possible reasons for unmatched (per spec §7)

Other Unmatched

Amount Variance is a cross-cutting descriptor on sweep batches — surfaces when bank-side and GL-side totals don't net to $0.00.

Sweep matching is line-level via Line Description + amount within a posting-date window. Confirmed Allison 2026-05-13: Line Description appears on the Fusion GL side and follows a conventional `JPM DISB[-modifier]*****` vocabulary (~15 distinct values since July). Colleen posts journals weekly (Mon/Tue), with delays for OOO or waiting on payroll/tax inputs; month-end final-week posts first business day of following month. Auto-match pairs bank lines to GL lines on Line Description + amount within ~1–10 business days of bank settlement. Same-description + same-amount collisions are rare per Allison; the batch view in the reconciliation modal is the fallback for ambiguous cases (bare `JPM DISB*` without modifier, 39% of entries, is the highest collision-risk subset). Future small process change (Option D per spec §9): if Colleen appends the bank-side End-to-End ID to her Line Description text, matching collapses to deterministic 1:1 like wires/checks. Beta (Stage 7): 575 entries included same-day with 275s (confirmed May 5/12 2026); write-back via Manual Reconciliation Service API closes the loop.