LexisNexis Embedded Innovation · Finance Discovery

Cash Management Intelligence — Delivery Overview

This document maps the capability tiers (Exception Intelligence → Automation Gap → Smart Intelligence) to product leadership's stated priority areas, shows how the user experience changes at each lifecycle stage in Mark Koussa's framework (Stage 3 Concept Build → Stage 4 Build Alpha → Stage 5 Alpha Testing with Customers → Stage 6 Validate/React → Stage 7 Beta → Stage 9 Iterate), outlines the integrations required, and positions the work within the product lifecycle. Intended for alignment with product leadership and handoff to the development team.

Problem context — why this matters

US — confirmed

~75%

of all LN global payment activity flows through 1 US disbursement account · 6 hrs/week reconciliation effort today · highest-stakes single account in scope · US payment account count pending Bobby (May 2026)

Global LN — confirmed

~5 FTE

annualized reconciliation labor (201 hrs/week) across 65 AP payment accounts + 1 US disbursement · AR accounts (~half of LN's 134 total) out of scope — handled by legacy systems, future project

RELX — extrapolated

~12–14 FTE

annualized reconciliation labor (directional, extrapolated from LN per-account ratio) · 364 bank accounts across 4 divisions · Elsevier ≈ LN per Bobby · Risk smaller (mostly US, fewer structural complexities)

Risk dimension: ~10% of payments estimated to fail silently — discovered only during manual queue review, no proactive alert. Confirmed downstream consequences: vendor service cutoffs, content contributors refusing work over late payment, office access issues due to delayed rent payments. Structural value beyond hours saved: today reconciliation is fractional work scattered across many people — no dedicated cash management function exists because the work can't be staffed that way. Auto-rec makes a focused, dedicated team operationally possible.

Scope and effort estimates · Bobby (Finance), May 2026 · 134 LN accounts total, 65 AP payment accounts in scope this iteration · 201 hrs/week derived from 65 × 3 hrs + 1 US disbursement × 6 hrs · RELX extrapolation uses LN per-account ratio (1.5 hrs/account/week) · Volume data (Apr 30 session): ~125–200 bank statement lines/week for largest US disbursement account (JPMorgan) · ~12% FX transactions (March data) · pilot = RELX team

Product leadership priority areas — coverage by capability tier

From product leadership · Apr 2026 · 3 stated priorities

Anomaly & Risk Detection

Near real-time detection of failed payments, duplicates, and anomalies. Proactive alerts to AP for resolution.

✓ Exception Intelligence — core deliverable

The primary value proposition of Exception Intelligence. The prototype demonstrates exception surfacing at concept fidelity. Fusion remains system of record; this sits on top of it.

Intelligent Cash Application & Matching

Improve match rates by recognizing patterns in remittances and learning from how exceptions are resolved.

◑ Exception Intelligence — partial ✓ Automation Gap — automated

Exception Intelligence identifies EI Engine-Matched candidates (human still confirms in Fusion). Automation Gap closes the loop: engine writes matches back to Fusion automatically. Routine queue disappears at Beta (Stage 7).

Cash Forecasting & Smarter Intelligence

Enhance forecast accuracy using historical patterns, seasonality, and customer payment behavior. Proactive alerting beyond the dashboard.

Smart Intelligence — Beta · requires Automation Gap audit log

Pattern learning, anomaly scoring, and forecasting require a clean reconciliation history — which Automation Gap's audit log provides. Not yet scoped beyond intent; feasibility and data requirements to be confirmed before Beta planning begins.

Lifecycle stages — Mark Koussa's framework · capability vs. delivery state

Capability tiers describe what the system does. Lifecycle stages describe where it sits in build/validate/ship. A capability can be demonstrated at one stage and ship to a customer at a later stage. The two cross-cut.

Stage	What it is	Where this work sits
Stage 3 — Concept Build (now)	Tangible artifact: clickable mock, working POC, or detailed storyboard. Aligns stakeholders and confirms domain logic with the SME.	✅ Where we are. Exception Intelligence demonstrated; ~12 SME-validated pain points mapped to built features; FX Variance JE CSV export wired up; Matthew Bender auto-watch wired up; spec is engineer-ready.
Stage 4 — Build Alpha	More complete version suitable for real customers. AI-assisted coding drives bulk of dev. Mark's framework times this at ~1 week; realistically ~2–4 weeks for cash mgmt given multi-bank adapter scope.	Bank: raw CAMT files dropped into existing temp storage. Fusion: CSV export drop into same temp storage or read-only API — whichever lands first. Allison's team uses it daily alongside Fusion. Read-only on Fusion side.
Stage 5 — Alpha Testing with Customers	Put outputs in front of customers as soon as possible. Freedom to experiment without exact alignment to current business strategy.	Extend to other RELX divisions' cash management teams. Read-only. Validates matching logic + workflow across multi-bank reality.
Stage 6 — Validate / React	Customer feedback drives spec/code updates. Code cleanup for production readiness.	Iterate on what multi-customer alpha exposes.
Stage 7 — Beta	Real logins, unsupervised usage. Commitment to availability with revisited SLAs. SRE support. Business unit involvement. Production gate.	Automation Gap lands here. Fusion REST API write-back via Manual Reconciliation Service. Service account + security review + audit log + rollback + pen test + multi-tenant hardening. The manual queue actually shrinks.
Stage 8 — GTM & Launch	Existing GTM process with train-the-trainer.	Standard org rollout.
Stage 9 — Iterate	Real usage data and customer feedback drive ongoing iteration.	Smart Intelligence lands here (informally: Gamma). Pattern learning, anomaly scoring, cash forecasting — depends on Beta's audit log as training data.

Why Fusion write-back lives at Beta, not Alpha. Mark's framework treats Build Alpha as ~1-week fast/scrappy customer-exposed-early for learning. Beta is the gate that commits to "real logins, unsupervised usage, SLAs, SRE support" — the production-grade gate. Fusion REST API write-back via Manual Reconciliation Service requires service account provisioning, write-back security review, production tier, rollback procedure, pen test sign-off, and multi-tenant hardening — all Beta-grade investments. Workflow nuance during alpha: with no write-back yet, Allison's team opens both Fusion and this app daily. Managed via alpha experience design (narrow scope, time-box, expectation-setting), not by relabeling the stage.

Capability tiers — what each one delivers and where it ships

Stage 3 → Stage 5

Concept Build → Build Alpha → Alpha Testing

Exception Intelligence

Exceptions surface the moment the bank file lands — before anyone has to go looking. Read-only on Fusion side throughout alpha; teams copy match decisions to Fusion manually.

⚡

Automatic classification — every bank line lands as either Matched (Fusion-Reconciled / EI Engine-Reconciled / Manually Reconciled) or Unmatched with a specific reason (Returned Payment / FX Pending JE / DD Pending / Duplicate Partial Refund / Other Unmatched). Amount Variance is a cross-cutting descriptor, not a separate status. No manual queue scanning to find exceptions.

🗂

All 5 transaction types — wires (USD + FX), checks, EFTs, direct debits, and ZBA sweeps, each with type-specific matching logic per spec §6.

⤓

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. Collapses Allison's multi-step Excel workaround for ~200 FX wires/month (weekly batch with month-end-close handling for late-month wires).

⚙

EI Engine auto-match — matches wires, checks, and EFTs (post-JPM-fix) on end-to-end ID + amount, the rule Fusion can't apply reliably (Fusion grabs unrelated transactions on wires, can't normalize leading zeros on checks, only matches amount+date on EFTs). Reconciled view shows match-source attribution per row: Fusion-Reconciled, EI Engine-Reconciled, or Manually Reconciled.

👁

Matthew Bender auto-watch — bank-side rows for Matthew Bender checks land throughout the month, but the matching system-side journal entry is posted only at month-end. The system auto-tags these rows to the Watching list at ingest (recognized by 8-digit padded check number); auto-matches on Transaction Number + amount once the month-end JE posts.

✉

AP escalation workflow — exceptions flagged for AP are batched into a structured email with a deep link. AP opens the link and sees a read-only view showing all Fusion identifiers needed to act. Reply routes back to the sender automatically. Sender identity is baked into the link at send time — no server required for the prototype. In production: injected from SSO/Azure AD at session start; user never configures it.

Workflow nuance during alpha. No write-back yet means Allison's team opens both Fusion and this app daily during Build Alpha (Stage 4) and Alpha Testing (Stage 5). Managed via alpha experience design — narrow scope, time-box, expectation-setting — not by relabeling the stage. Sustained workload-shrinking benefit lands at Beta when write-back ships.

Stage 7 — Beta

Production gate · write-back live · queue shrinks

Automation Gap

Routine reconciliation handled automatically. The manual queue shrinks to true exceptions only.

⚙

Matching engine — string normalization resolves the formatting gaps (leading zeros, case, whitespace) that block Fusion's auto-match. Wires, checks, EFTs reconciled without human clicks.

↩

Fusion write-back via Manual Reconciliation Service API — EI Engine matches written directly to Fusion as bank-line ↔ GL-record pairs. Routine USD wire / Check / EFT / Matthew Bender / FX wire reconciliations stop appearing in the manual queue.

📜

Immutable audit log — every automated match recorded with timestamp, matched IDs, and match type. Required for compliance — and the training data foundation Smart Intelligence needs at Beta.

🎯

True exceptions only — FX wires, direct debits (informal match by design), unresolvable mismatches, and anomalies remain for human review. Everything else is handled.

More complex than it looks — SME sessions confirmed (Allison + Bobby + Joanne, May 8): EFT batched-delivery is a JPMorgan-side fix, not the system's job (carve-out per spec §9); CC sub-types require an IND NAME lookup table (7 variants, ORIG CO NAME useless for distinction); IC Entry is intercompany journal (Corporate RELX reimburses LN); Matthew Bender checks match on Transaction Number AND Journal Line Description; Returned Payment + Duplicate Partial Refund need a bank-line clustering primitive (multi-bank-row link distinct from bank↔GL match); Sweep matching is line-level via Line Description + amount within a posting-date window (per Allison 2026-05-13); PA Supreme Court DD is N:1 subset-sum (per Allison's P460 Matching.xlsx 2026-05-12); other DD subtypes pending; Direct Debit rules are subtype-keyed (bank+subtype), not type-keyed; bank-specific logic isolated to a translation/adapter layer so adding a new bank = one new adapter, not changes to matching engine.

Stage 9 — Iterate (Gamma)

Post-launch · requires Beta audit log

Smart Intelligence

System learns from history and alerts before problems become visible — addresses product leadership's forecasting priority.

🧠

Pattern learning — vendor payment behavior, typical amounts, and seasonal variation modeled from Automation Gap's audit log. Anomaly scoring shifts from binary to contextual.

🔔

Proactive alerts via Teams / email — high-priority exceptions pushed without requiring the tool to be open. A $2M failed wire surfaces within minutes, not during queue review.

📈

Cash forecasting — product leadership's third stated priority. Approach and data requirements not yet scoped. Would likely benefit from Automation Gap's reconciliation history, but could also be explored against existing Fusion GL/payment data. Feasibility unconfirmed.

⚠

Sequencing is non-negotiable. Smart Intelligence cannot exist without Automation Gap's audit log as training data. No Automation Gap = no Smart Intelligence.

Value case — Exception Intelligence + Automation Gap · click to expand

Exception Intelligence — detection and tracking overhead eliminated

Exception Intelligence surfaces exceptions at the top of the queue — the team no longer discovers problems mid-review. Formula: exceptions per week × time to detect and handle manually today = weekly overhead eliminated. Note: time savings alone understates the value for Returned Payment and Duplicate Partial Refund — tracking risk (items that fall through today) matters more. Cells marked "—" require confirmed data from the cash management team.

Exception type	How it surfaces today	confirm with cash management teamVolume/week	confirm with cash management teamTime to find + handle per item today	Est. time saved/week
Returned Payment	Discovered mid-queue in Fusion — no proactive alert. Found during manual reconciliation review. Original + return are two bank-side rows that belong together.	—	—	—
Duplicate Partial Refund	Discovered mid-queue. Two bank lines for one GL entry plus a refund line; tracked manually until GL team resolves. Detection signals open (spec §12 Q5a).	—	—	—
FX Pending JE	Found during reconciliation. Tracked manually for weekly variance journal entry — multi-step Excel workaround replaced by FX Variance JE CSV export.	—	—	—
DD Pending	Bank-side withdrawal occurred but AP ledger entry hasn't posted yet. No proactive surfacing in Fusion today.	—	—	—
Other Unmatched	No GL candidate shown in Fusion — manual search required per item to find matching entry.	—	—	—
Total — weekly exception detection overhead (Exception Intelligence)		—	—	—

Tracking risk (not captured above): For Returned Payment and Duplicate Partial Refund, time savings may be less significant than the risk of an item falling through the cracks today — a returned $2M wire caught the next day vs. the same day has cost implications independent of team hours (and creates the AP void-risk window — see Pain Point 12). Ask: has a returned payment or duplicate ever been caught late, and what happened?

Automation Gap — daily manual queue reduction at Beta (Stage 7)

Automation Gap eliminates the manual queue items that Fusion should already be matching — reference format inconsistencies (leading zeros, whitespace) that our engine normalizes and closes. Formula: matchable items per day × time per manual reconciliation today = daily time saved. Cells marked "—" require confirmed data from the cash management team.

Transaction type	Automation Gap matches when	confirm with cash management teamItems/day currently going to manual queue	confirm with cash management teamMinutes per manual reconciliation today	Est. time saved/day
Wire 495 (USD)	Payment Reference Number — leading zero or whitespace mismatch	—	—	—
Check	Check Number → Transaction Number — format mismatch	—	—	—
EFT	Batch-level (code 466) — reference format mismatch, pending Bobby confirming unique identifier exists in payment files. Code 168 (returns) is a separate manual workflow — may not be automatable. matching field unconfirmed	—	—	—
Total — daily manual queue reduction (Automation Gap)		—	—	—

Items not eliminated by Automation Gap — these require human judgment regardless: Returned Payment (AP handles reissuance), Duplicate Partial Refund (GL reversal required first; detection approach is an open design problem per spec §12 Q5a — duplicates typically won't share a payment reference), FX Pending JE (variance journal entry created weekly with month-end-close handling; the FX Variance JE CSV export collapses the workaround), Direct Debit (subtype-keyed rules per spec §9; PA Supreme Court is N:1 subset-sum and potentially automatable per Allison 2026-05-12; CC uses Remarks 9 IND NAME; IC Entry is intercompany journal — CC and IC Entry matching shape pending Allison 2026-05-13), Sweep (line-level via Line Description + amount within posting-date window per Allison 2026-05-13; 575 entries grouped same-day with 275s).

User journey — how the daily workflow changes

Today — Fusion only (no tool)

Manual queue work

Oracle Fusion only. No prioritization. Exceptions found by encountering them. No way to track follow-ups, watch items, or send AP a structured handoff.

Bank file arrives. No automatic processing.

Cash management team opens Fusion reconciliation queue — unordered, full volume.

Works through items one by one. Exceptions discovered mid-queue

Manually matches wires on reference, checks on check number. Routine volume is the majority of time.

FX wires batched weekly into a variance JE; held in FX Pending JE state until then. Sweep batched manually by memory.

No way to write notes per item — context lives in head, side notes, or email threads.

No "watch this" mechanism — items needing follow-up either get re-encountered or forgotten.

AP escalation = ad-hoc screenshot emails to ap.globalhelpdesk@lexisnexis.com — no structured payload, no reply routing, no tracking.

Failed payments or duplicates may sit unresolved until discovered.

›

Concept Build → Build Alpha (Stage 4) · Exception Intelligence

Exception intelligence

Bank file + Fusion export → exceptions surfaced before queue is opened. Fusion stays system of record. Notes, Watching state, and structured AP escalation arrive here.

Bank file arrives. Exceptions classified automatically.

Cash management team sees a prioritized exception list — Returned Payment, FX Pending JE, DD Pending, Duplicate Partial Refund, Other Unmatched — before opening Fusion. Amount Variance is a cross-cutting descriptor (filter toggle), not a separate status.

EI Engine-Matched tab shows items the engine identified as likely matches. Team confirms in Fusion.

Routine reconciliation still manual in Fusion. Output is CSV / formatted file for manual handoff. Queue is ordered, not random.

Personal notes per item — write context to self ("waiting on AP", "check after next bank file"). Notes persist with the item across sessions and surface in the AP escalation email when sent.

Watching state — flag an item to revisit without losing it. Aging surfaces stalled items after a tunable threshold.

AP escalation via structured deep link — replaces screenshot-email workflow. AP opens link, sees read-only view with all Fusion identifiers needed, replies route back to original sender automatically.

FX wires, sweep batch logic, and direct debit workflows surfaced with context — no hunting.

›

Beta (Stage 7) · Automation Gap · production gate (write-back live)

Automation gap closed

Matching engine writes reconciliations back to Fusion. Cash management team works true exceptions only.

Bank file + Fusion GL export processed by matching engine. Wires, checks, EFTs reconciled automatically where reference data aligns.

Reconciliation matches written back to Fusion via REST API. No manual Fusion clicks for routine items.

Manual queue: true exceptions only. Failed payments, duplicates, unresolvable mismatches — items that genuinely need human judgment.

Immutable audit log records every automated match. Traceability for compliance and month-end.

EI Engine-Matched tab from Exception Intelligence disappears — those items now auto-reconciled.

›

Beta · Smart Intelligence · requires Automation Gap audit log

Smarter intelligence

Pattern learning, anomaly scoring, proactive alerts, and cash forecasting. Built on Automation Gap's clean data pipeline.

System learns from reconciliation history. Vendor payment patterns, typical amounts, seasonal variation — modeled automatically.

Anomaly detection becomes smarter: not just "this failed" but "this is unusual for this vendor at this time of month."

Proactive alerts pushed via Teams / email — team doesn't need to open the tool to know something needs attention.

Cash forecast inputs generated from historical reconciliation data + payment behavior patterns.

Exception scoring: priority ranked by impact, not just type. A $2M failed wire ranks above a $400 duplicate.

Integration architecture — data flow

Integration requirements by lifecycle gate

⚠ Unresolved architecture decision — bank-side data source. The table below assumes the raw bank file (ISO 20022 / CSV) is ingested directly from JPMorgan/Citi. An alternative is to read bank statement lines from Oracle Fusion's Cash Management API — Fusion already imports the bank file and may expose all the same data via a single integration point, avoiding a separate bank data feed. The direct-file approach enables earliest detection and full data fidelity but requires a separate feed, IT setup, and security review for handling raw financial data outside Fusion. The Fusion-first approach is simpler and automatically provides the internal bank statement line ID needed for Automation Gap write-back — but depends on Fusion's API exposing all fields needed for anomaly detection (transaction codes, full End-to-End IDs, failure status), which has not been verified. This must be confirmed during Fusion API scoping before Beta (Stage 7) begins.

Integration	Build Alpha (Stage 4) Exception Intelligence (internal validation)	Beta (Stage 7) Automation Gap (production · write-back live)	Beta Smart Intelligence	User implication
Bank file (JPMorgan / Citi) ISO 20022 XML or CSV · direct from bank · assumed	Arch TBD	Arch TBD	Arch TBD	Current assumption: bank sends raw file directly to our pipeline. Alternative: read bank statement lines from Fusion's Cash Management API instead (see note above). All ID fields must be ingested as strings regardless of source — leading zeros in reference numbers must be preserved or matching fails.
Fusion Cash Management API (bank statement lines) Alternative to direct bank file · read-only	Arch TBD	Arch TBD	Arch TBD	If Fusion's Cash Management API exposes all required fields (transaction codes, End-to-End IDs, failure status), this becomes the preferred source — single integration point, no separate bank data feed, internal bank statement line ID included automatically. Must be validated during Fusion API scoping.
Fusion GL export Daily pull · read-only	Required	Required	Required	Exception Intelligence reads for exception analysis. Automation Gap reads for matching. Smart Intelligence reads as historical input to pattern models. Must include Payment Reference Number, Transaction Number, Source, Amount, Currency, Date, and internal GL transaction ID.
Fusion internal bank statement line ID Contact: Fusion IT	Not required	Blocking dependency	Inherited	Automation Gap cannot write matches back to Fusion without a stable unique ID for each bank statement line. Must be confirmed before Beta (Stage 7) begins. Smart Intelligence inherits this from Automation Gap.
Fusion reconciliation REST API Write · programmatic match submission	Not required	Blocking dependency	Inherited	The mechanism by which Automation Gap closes matches in Fusion without a human. Requires confirmed endpoint, error handling spec, and IT/security approval. Smart Intelligence inherits this from Automation Gap.
Service account (Cash Manager role) Auth · IT/security approval required	Not required	Blocking dependency	Inherited	The service account used to call the Fusion API. Requires IT and security sign-off. Lead time unknown — needs to be initiated early in Automation Gap planning. Smart Intelligence inherits.
Matching engine String normalization · per-type rules	Not required	Beta (Stage 7)	Inherited	Runs string normalization before comparison (leading zeros, whitespace, case). Per-type rules: wires on payment reference, checks on check number, EFTs on reference (pending confirmation). Exact match only in v1. Smart Intelligence may extend to fuzzy/learned matching.
Scheduled pipeline job Daily trigger after bank file receipt	Not required	Beta (Stage 7)	Inherited + extended	Orchestrates the daily bank file → GL export → matching engine → Fusion write-back sequence. Smart Intelligence extends with model inference step in the same pipeline. Must include failure alerting if bank file doesn't arrive or Fusion export is stale.
Immutable audit log Every automated match recorded	Not required	Beta (Stage 7)	Blocking dependency — future direction	Records timestamp, matched IDs, match type (system vs. human), and matched-by. Required for compliance. The future direction intelligence layer would likely use this history as training data for pattern models, but that dependency is not yet confirmed.
Output to Fusion (Exception Intelligence interim) CSV / formatted spreadsheet · manual handoff	Required	Replaced by API	Not applicable	Exception Intelligence manual handoff format. Cash management team takes the output and executes reconciliation actions in Fusion. Automation Gap eliminates this step — the API writes directly.
AI pattern model Vendor behavior · seasonality · anomaly scoring	Not required	Not required	Smart Intelligence	Trained on Automation Gap audit log history. Models vendor payment patterns, expected amounts, timing. Enables "this is unusual for this vendor" scoring rather than binary failed/not-failed detection.
Proactive alert delivery Teams / email push · no dashboard required	Not required	Not required	Smart Intelligence	Pushes high-priority exceptions to the team (and AP) without requiring them to open the tool. Failed $2M wire surfaces in Teams within minutes of bank file processing — not discovered during manual queue review.
Cash forecasting engine Historical patterns + payment behavior	Not required	Not required	Smart Intelligence	Product leadership's third stated priority. Requires sufficient reconciliation history (Automation Gap audit log) to model seasonal patterns and customer payment behavior. Cannot be built accurately on incomplete or manually-reconciled data.

Product lifecycle position

9-stage embedded innovation lifecycle · current position highlighted

Substantive Stage 1–2 work complete · preparing for formal review with leadership

1
Concept Sprint

2
Prioritize

3
Concept Build ◀

SME
Review ◀

Keep/
Kill

4
Build Alpha

5
Alpha Test

6
Validate

7–9
Ship

In progress

Stages 1–2

Concept Sprint and Prioritize substantively complete. Problem statement, target workflow, and capability-tier roadmap defined (Exception Intelligence → Automation Gap → Smart Intelligence). Prototype built and iterated across multiple SME sessions. Pending formal review with leadership.

Current — Stage 3 / SME Review

Concept Build + Iterative SME Review

Prototype demonstrates Exception Intelligence value. SME review with the cash management team is ongoing. 3 open questions remain (EFT matching field, 575 handling, Matthew Bender checks). DD matching and transaction codes resolved 2026-04-30. Mandatory SME sign-off required before Keep/Kill.

Next gate

Keep/Kill → Stage 4 Build Alpha

Once open questions resolved and SME sign-off obtained: move to Build Alpha (~1 week). Proof of Concept Review (mandatory) before any customer exposure. Automation Gap dependencies (Fusion API, service account, bank line ID) must be scoped with Finance leadership's team in parallel.

Packaging for leadership and the dev team

For leadership

Strategic framing. Product leadership's priorities are addressed. Exception Intelligence is demonstrable today — Automation Gap has clear dependencies and sequencing.

✓

Prototype demonstrates Exception Intelligence at concept fidelity. Validated with the cash management team. Addresses product leadership's highest priority area directly. Build Alpha (Stage 4) and Alpha Testing (Stage 5) run read-only — Allison's team and other RELX divisions use it alongside Fusion. Beta (Stage 7) is the production gate where Fusion write-back lands and the manual queue actually shrinks.

✓

Automation Gap roadmap defined. Matching engine, Fusion API write-back, audit log — scoped, sequenced, dependencies identified.

3 open questions remaining with the cash management team. DD matching and transaction codes resolved 2026-04-30. Remaining: EFT matching field, 575 handling, Matthew Bender checks. SME sign-off needed before Keep/Kill. Follow-up call 2026-05-06.

Beta (Stage 7) requires Fusion IT engagement. Bank statement line ID and API access require engagement with Fusion IT. Should be initiated in parallel with the 4a internal validation pass — not sequential. 4b is the first true customer alpha and the gate where time-savings claims to customers become real.

Cash forecasting is on the Beta roadmap, not out of scope. Product leadership listed it as a priority. The message to leadership: Smart Intelligence is on the roadmap — but it requires Automation Gap's audit log as training data. Sequencing is non-negotiable.

For the development team

What to hand over, what format, what's confirmed vs. pending. Version control setup needed before handoff.

✓

cash-management.html — working Exception Intelligence prototype. All 5 transaction types built, modal reconciliation flows, exception logic, sweep batch reconciliation. Single-file HTML, all logic inline.

✓

workflow-overview.html — per-type workflow reference. Matching fields, anomaly types, open questions flagged inline with confirmed vs. unconfirmed labels.

✓

CLAUDE.md / coding-notes.md — domain rules, open questions master list, build assumptions, Automation Gap technical requirements spec. Dev-ready reference.

GitHub / version control not yet set up. Must be established before handoff so there is traceable artifact history. All prototype files are in a single local directory — straightforward to initialize.

Placeholder content flagged inline. Any string marked [CONFIRM WITH CASH MANAGEMENT TEAM] is not sourced from the transcript. Dev team must not treat these as confirmed domain rules.

LexisNexis Embedded Innovation · Danielle Brown · For internal review only · Last updated April 2026

How each exception type works

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 the 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 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; future direction 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 DebitPA Supreme Court: N:1 subset-sum (confirmed 2026-05-12) — bank-side P460 lines accumulate, AP creates one consolidated Payables entry, match by subset summing to total. Other DD subtypes pending.

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. Distinct from Fusion-Reconciled (Fusion auto-matched it) and Manually Reconciled (a human matched it). Exception Intelligence: informational read-only panel. Automation Gap (Beta / Stage 7): 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 Manual Reconciliation Service API. Same mechanism as Unmatched — clean 1-to-1 write-back.

Automation Gap — automatable write-back at Beta (Stage 7)

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 12 (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). Exception Intelligence makes the handoff a tracked, timestamped escalation visible under the AP Escalations filter — cannot be missed or forgotten.

Quantify

• How many failed payments occur per week?

• Has one ever been missed or caught late — and what was the impact?

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 tracking of the duplicate flag — likely a mental note, email, or sticky. Exception Intelligence provides a structured flag with timestamp, both GL candidates visible, held under a dedicated filter until the GL team resolves.

Quantify

• How many duplicates occur per week?

• How are these tracked today between flagging and GL team resolution?

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 reminder or tracking for the weekly FX journal entry. Exception Intelligence holds FX wires in a visible state between the bank date and the next variance JE — nothing falls through between sessions.

Quantify

• How many FX wires (code 514) land per month?

• Has an FX wire ever missed month-end close because it wasn't tracked?

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?

→

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. Should reconcile automatically once reference formats align. If unmatched: the GL candidate with the matching Payment Reference Number is shown — verify and confirm.

FX wire (514)

Bank amount is in foreign currency; GL amount is the USD equivalent. Amounts will not match. A manual journal entry is required (weekly batch with month-end-close handling for late-month wires) to record the FX conversion before reconciliation can be completed.

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).

Check

Standard checks and Matthew Bender checks (handling may differ — see open question)

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.

Normal workflow

Check clears the bank. System matches check number on bank side to Transaction Number in GL. If Fusion auto-reconciles: no action needed. If unmatched: one GL candidate is shown with the matching Transaction Number — verify and confirm.

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 2026). Matthew Bender bank-side rows pre-month-end land as Other Unmatched + Auto-watched.

≈

EFT (Electronic Funds Transfer)

ACH-based payments; matching field pending confirmation

How matching works

End-to-End ID

bank side

Payment Reference Number

GL side (assumed)

unconfirmed

Assumed same as wire. Waiting on confirmation from cash management team's Philippines contact.

Normal workflow

Once the matching field is confirmed, expected to follow the same pattern as USD wires — string comparison on the reference field, 1-to-1 match, should reconcile automatically when reference formats align.

Possible reasons for unmatched (per spec §7)

Returned Payment Duplicate Partial Refund Other Unmatched

←

Direct Debit

PA Supreme Court (Customer Ref: P460) · transaction code 455 (global banking standard for direct debits — confirmed 2026-04-30) · Note: Citibank Credit Card = CC type (Remarks 9 IND NAME identifies individual cards; ORIG CO NAME = "CITIBANK, N.A." for all CCs — confirmed 2026-05-05), RELX CENTRE CTA US = IC Entry type (intercompany journal, Corporate RELX reimburses LN — confirmed 2026-05-05). DD matching rules are subtype-keyed (bank + subtype), not type-keyed — see spec §9.

How matching works

Dollar amount

bank side → GL side

Journal entry type

confirms it's the right entry

confirmed 2026-04-30

Matching is informal, not field-to-field. The cash management team identifies the corresponding journal entry by dollar amount and the fact that it's a journal entry (not an AP payment). Volume is low enough that the exact dollar amount uniquely identifies each direct debit — no ID comparison needed. The booking team sends the cash management team a copy of the journal to verify journal ID and amount before reconciling.

Remarks 9 / Additional Entry Information: This bank field confirms which credit card a direct debit belongs to (visible on bank statement, not surfaced by default in Fusion). The cash management team uses it to know what next steps are needed (e.g., which team books the entry). Currently requires opening each transaction in Fusion or using her Excel file to see. Surfacing this field visibly in the POC is a confirmed improvement.

Normal workflow

Direct debits do not go through AP — they are posted as manual journal entries in the GL. The cash management team sees the debit arrive on the bank side and notifies the booking team (via email). The booking team creates the journal entry and sends the cash management team a copy. The cash management team then matches journal ID and amount, confirms, and reconciles. PA Supreme Court has a unique variant: AP holds invoices and processes them in batches only after Kathy Corson prompts them (several payments may accumulate before AP processes). Exact matching details for PA Supreme Court to be confirmed when next transaction arrives (expected soon per cash management team, 2026-04-30).

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.

↕

Sweep (ZBA)

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

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 (negative amounts) are excluded from the default selection and handled separately.

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. Code 575 entries are included in batch balance calculations (confirmed May 5 2026).