LexisNexis Embedded Innovation · Finance Discovery

Cash Management Intelligence — Delivery Overview

This document maps the two-phase build plan to Emma Harris's stated priority areas, shows how the user experience changes at each phase, outlines the integrations required, and positions the work within the product lifecycle. Intended for alignment with Mark Koussa and handoff to the development team.

Emma Harris priority areas — coverage by phase

From Emma's email · Apr 2026 · 3 stated priorities

Anomaly & Risk Detection

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

✓ Phase 1 — core deliverable

This is the primary value proposition of Phase 1. The prototype demonstrates exception surfacing today. 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.

◑ Phase 1 — partial ✓ Phase 2 — automated

Phase 1 identifies EI Engine-Matched candidates (human still confirms in Fusion). Phase 2 closes the loop: engine writes matches back to Fusion automatically. Routine queue disappears.

Cash Forecasting & Smarter Intelligence

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

Future direction — unscoped · likely needs Phase 2 data first

Pattern learning, anomaly scoring, and forecasting would benefit from a clean reconciliation history — which Phase 2's audit log would provide. Not a formal phase and not yet scoped. Feasibility and data requirements need to be confirmed before this can be planned.

Phase overview — 2 formal phases + future direction

Phase 1 · Now · Prototype complete

Payment Exception Intelligence

Exceptions surface the moment the bank file lands — before anyone has to go looking.

⚡

Automatic detection — failed payments, duplicates, and amount variances classified and severity-ranked on file arrival. No manual queue scanning to find them.

🗂

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

📋

CSV export for Fusion handoff — cash management team (validated with Allison Lopez and Bobby, April 2026) still executes reconciliation actions in Fusion. Output is structured for manual import. Fusion remains system of record.

🔍

System Match view — engine identifies likely matches Fusion missed due to reference format issues (leading zeros, whitespace). User confirms before reconciling.

Phase 2 · Future · 3 blocking dependencies

Close the 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 REST API — confirmed matches written directly to Fusion. System Match items from Phase 1 disappear from the manual queue entirely.

📜

Immutable audit log — every automated match recorded with timestamp, matched IDs, and match type. Required for compliance — and the training data foundation for future intelligence capabilities.

🎯

True exceptions only — FX wires, direct debits, unresolvable mismatches, and anomalies remain for human review. Everything else is handled.

→

Future Direction · Requires Phase 2 first

Smarter Intelligence

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

🧠

Pattern learning — vendor payment behavior, typical amounts, and seasonal variation modeled from Phase 2 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 — Emma's third stated priority. Approach and data requirements not yet scoped. Would likely benefit from Phase 2's reconciliation history, but could also be explored against existing Fusion GL/payment data. Feasibility unconfirmed.

⚠

Not a formal phase — this is future direction, contingent on Phase 2's audit log being live. The audit log Phase 2 builds is the only viable training data source. No Phase 2 = no future direction intelligence.

Value case — Phase 1 + Phase 2 · click to expand

Phase 1 — detection and tracking overhead eliminated

Phase 1 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 Failed Payment and Duplicate — 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
Failed Payment	Discovered mid-queue in Fusion — no proactive alert. Found during manual reconciliation review.	—	—	—
Duplicate	Discovered mid-queue. Tracked manually (email, note, memory) until GL team resolves.	—	—	—
Amount Variance (FX wire)	Found during reconciliation. Tracked manually for month-end journal entry — no structured reminder.	—	—	—
Unmatched	No GL candidate shown in Fusion — manual search required per item to find matching entry.	—	—	—
Total — weekly exception detection overhead (Phase 1)		—	—	—

Tracking risk (not captured above): For Failed Payment and Duplicate, time savings may be less significant than the risk of an item falling through the cracks today — a failed $2M wire caught the next day vs. the same day has cost implications independent of team hours. Ask: has a failed payment or duplicate ever been caught late, and what happened?

Phase 2 — closing the automation gap

Phase 2 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	Phase 2 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	Same as wire — reference format mismatch matching field unconfirmed	—	—	—
Total — daily manual queue reduction (Phase 2)		—	—	—

Items not eliminated by Phase 2 — these require human judgment regardless: Failed Payment (AP must re-initiate), Duplicate (GL reversal required first), Amount Variance / FX (journal entry required), Direct Debit (matching workflow unconfirmed), Sweep (batch balance must be verified).

User journey — how the daily workflow changes

Today

Manual queue work

Oracle Fusion only. No prioritization. Exceptions found by encountering them.

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 deferred to month-end. Sweep batched manually by memory.

Failed payments or duplicates may sit unresolved until discovered.

›

Phase 1 · Now

Exception intelligence

Bank file + Fusion export → exceptions surfaced before queue is opened. Fusion stays system of record.

Bank file arrives. Exceptions classified automatically.

Cash management team sees a prioritized exception list — failed payments, duplicates, amount variances — before opening Fusion.

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.

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

›

Phase 2 · Future

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 Phase 1 disappears — those items now auto-reconciled.

›

Future Direction · requires Phase 2

Smarter intelligence

Pattern learning, anomaly scoring, proactive alerts, and cash forecasting. Built on Phase 2'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 — Phase 1 vs Phase 2

⚠ 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 Phase 2 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 Phase 2 begins.

Integration	Phase 1	Phase 2	Future Direction	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	Phase 1 reads for exception analysis. Phase 2 reads for matching. Future direction 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 Open question — Fusion IT / Johanne's team	Not required	Blocking dependency	Inherited	Phase 2 cannot write matches back to Fusion without a stable unique ID for each bank statement line. Must be confirmed before Phase 2 build begins. Future direction inherits this from Phase 2.
Fusion reconciliation REST API Write · programmatic match submission	Not required	Blocking dependency	Inherited	The mechanism by which Phase 2 closes matches in Fusion without a human. Requires confirmed endpoint, error handling spec, and IT/security approval. Future direction inherits this from Phase 2.
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 Phase 2 planning. Future direction inherits.
Matching engine String normalization · per-type rules	Not required	Phase 2 build	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. Future direction may extend to fuzzy/learned matching.
Scheduled pipeline job Daily trigger after bank file receipt	Not required	Phase 2 build	Inherited + extended	Orchestrates the daily bank file → GL export → matching engine → Fusion write-back sequence. Future direction 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	Phase 2 build	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 (Phase 1 interim) CSV / formatted spreadsheet · manual handoff	Required	Replaced by API	Not applicable	Phase 1 manual handoff format. Cash management team takes the output and executes reconciliation actions in Fusion. Phase 2 eliminates this step — the API writes directly.
AI pattern model Vendor behavior · seasonality · anomaly scoring	Not required	Not required	Future direction	Trained on Phase 2 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	Future direction	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	Future direction	Emma's third stated priority. Requires sufficient reconciliation history (Phase 2 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 Mark

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 two-phase roadmap defined. Prototype built and iterated across multiple SME sessions. Pending formal review with Mark.

Current — Stage 3 / SME Review

Concept Build + Iterative SME Review

Prototype demonstrates Phase 1 value. SME review with the cash management team is ongoing. 5 open questions remain (EFT matching field, DD matching field, 575 handling, Matthew Bender checks, transaction codes). 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. Phase 2 dependencies (Fusion API, service account, bank line ID) must be scoped with Johanne's team in parallel.

Packaging for leadership and the dev team

For leadership

Strategic framing. Emma's priorities are addressed. Phase 1 is demonstrable today — Phase 2 has clear dependencies and sequencing.

✓

Prototype ready to demo. Phase 1 exception intelligence is built and validated with the cash management team. Addresses Emma's highest priority area directly.

✓

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

5 open questions with Allison. SME sign-off needed before Keep/Kill. Next session with the cash management team resolves these. Low risk — prototype logic is sound, answers refine edge cases.

Phase 2 requires Fusion IT engagement. Bank statement line ID and API access require Johanne's team or Fusion IT. Should be initiated in parallel with Phase 1 alpha build — not sequential.

Cash forecasting is future direction, not out of scope. Emma listed it as a priority. The message to Mark: it is on the roadmap — but it requires Phase 2's audit log as its data foundation. 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 Phase 1 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, Phase 2 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 · 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 Phase 2 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?

System can write result back to Fusion automatically (Phase 2)

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

Phase 1 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

Phase 1 value case — confirm with cash management team

Steps this replaces

None — Fusion already reconciled before the queue loaded. Phase 1 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 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

Phase 1 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 — Phase 2 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 Phase 2 engine before reaching this point — they reconcile as System Match.

Human step required — GL entry must exist in Fusion first

Phase 1 value case — confirm with cash management team

Steps this replaces

Manual GL search in Fusion — hunting for a matching entry without a highlighted candidate. Phase 1 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?

System Match

Engine identified a likely match that Fusion could not auto-confirm

Reference format mismatch (leading zero, whitespace) — engine matched on reference after normalization. Phase 1: informational read-only panel. Phase 2: these reconcile automatically.

Detection

Fusion identified a GL candidate with a matching amount and approximate reference, but the reference strings did not match exactly — e.g., a leading zero difference, whitespace, or slight format variation prevented the auto-match from completing.

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

User journey

Sees transaction in list with System Match badge — engine has already identified the likely 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 Phase 1; Phase 2 eliminates this step entirely

Phase 1 outcome

In Phase 1, System Match is informational only. Clicking the transaction opens a read-only panel — the same layout as Auto-Reconciled — showing the bank entry and the matched GL entry side by side. A blue alert reads: "System match — our engine matched this on reference after normalization. GL entry: [ref]. Phase 2 reconciles these automatically." There is no Reconcile button. The reconciliation still happens in Fusion. The value in Phase 1 is visibility: the engine has already identified the match and named the specific GL entry. In Phase 2, these items disappear from the manual queue entirely — the engine writes the confirmed match to Fusion without any human step.

Fusion

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

Phase 2 — automatable write-back

Phase 1 value case — confirm with cash management team

Steps this replaces

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

Quantify (Phase 2 key metric)

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

Failed Payment

Bank confirms this payment was not processed

RTN code / NSF / stop payment — payment must be re-initiated by AP

Detection

Bank return file includes a return code (RTN) indicating the payment failed. The bank line exists in the file but funds were not transferred.

Wire / EFTBeneficiary bank unreachable; ACH return code

CheckNSF; account closed at receiving bank; stop payment placed

Direct DebitFailed payment scenario unconfirmed for DD — validate with cash management team unconfirmed

User journey

Sees Failed Payment alert with failure reason. GL entry is shown — payment was authorized but never cleared the bank.

Clicks "Escalate to AP" — flags transaction for AP team to investigate and re-initiate

POC marks as Escalated to AP with timestamp. Item moves to AP Escalations filter. Exportable as CSV for email handoff to AP team.

Phase 1 outcome

Opening a Failed Payment item shows the reconciliation modal with a red alert: "Bank return file confirms this payment was not processed." The GL entry that was authorized appears in the candidates table — the payment was initiated but funds never cleared. The primary action is "Escalate to AP": clicking it logs a timestamp, marks the transaction as Escalated, and moves it to the AP Escalations filter. The Reconcile button is present but should not be used until AP re-initiates the payment and a replacement transaction clears the bank. The tool makes the handoff to AP a tracked, visible event rather than a manual notification.

Fusion

AP team re-initiates the payment in Fusion — this is a payments workflow, not a reconciliation action. GL entry may need reversal. Reconciliation follows after the new payment clears the bank.

Human step required — AP re-initiates payment in Fusion

Phase 1 value case — confirm with cash management team

Steps this replaces

Manual AP notification (Teams message or email). Phase 1 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

Multiple GL entries found with the same reference for one bank line

Possible duplicate GL entry — scenario definition needs cash management team confirmation before finalizing

Detection

POC finds two GL entries matching the same bank reference and amount. One bank line, two GL candidates — suggests the same payment may have been entered twice in the GL.

⚠ Confirm with cash management team: Is this scenario (a) two GL entries for one cleared bank payment, or (b) two bank lines for one GL entry? These have different recommended actions. Current prototype models case (a) — two GL entries, one bank line. If case (b) is the real scenario, the detection logic and recommended action both need to change.

User journey

Sees two GL candidates, both matching on reference and amount. Alert warns not to reconcile both.

Clicks "Flag for Investigation" — sends to AP/GL team to identify which entry is the duplicate and reverse it

POC marks as Flagged for Investigation. Exportable as CSV. After AP resolves, user returns to reconcile the correct GL entry.

Phase 1 outcome

Opening a Duplicate item shows two GL candidates in the table — both matching the same bank reference. The alert reads: "Two GL entries found with the same reference for this bank line. Identify which is the original. Reconcile only the correct entry — flag this transaction for investigation before proceeding." The "Flag for Investigation" button is the recommended first action: it holds the transaction in a visible queue with a timestamp and records that it was flagged for a duplicate. Once the GL team reverses the duplicate entry in Fusion, the user returns and reconciles the correct remaining entry. The tool provides the audit trail: what was flagged, when, and what both candidates looked like.

Fusion

AP/GL team reverses the duplicate GL entry in Fusion. User then returns to the POC and reconciles the correct entry. GL reversal cannot be automated through the reconciliation API.

Human step required — GL reversal in Fusion first

Phase 1 value case — confirm with cash management team

Steps this replaces

Manual tracking of the duplicate flag — likely a mental note, email, or sticky. Phase 1 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?

Amount Variance

Bank amount does not match GL amount

Applies to FX wires (code 514) only — currency conversion creates an expected difference that requires a journal entry before reconciliation

Detection

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

Wire 514Amount variance expected — journal entry required at month end

Wire 495Amount Variance removed — USD amounts must match exactly

EFT / CheckAmount Variance removed — amounts must match exactly

Direct DebitAmount Variance scenario unconfirmed unconfirmed

User journey

Sees FX wire with amber alert — bank amount shown in foreign currency, GL amount in USD. Difference is flagged as expected due to FX conversion.

Creates a manual journal entry in Fusion to record the FX conversion (done outside the POC at month end)

Returns to POC, selects updated GL entry, clicks Reconcile. POC records Manually Reconciled.

Phase 1 outcome

The tool holds the transaction in an Amount Variance state — a clear flag that the FX conversion journal entry hasn't been created yet and reconciliation cannot complete. When the user creates the journal entry in Fusion at month-end (a separate step outside the tool), they return, select the updated GL entry, and reconcile. The tool records the final match with a timestamp and both IDs. Nothing falls through the cracks between the bank statement date and month-end close.

Fusion

Journal entry must be created in Fusion first (manual, month-end step). Once created, Phase 2 can write the reconciliation match back via API. Journal entry creation itself is not automatable through the reconciliation API.

Human step first — journal entry required in Fusion

Phase 1 value case — confirm with cash management team

Steps this replaces

Manual reminder or tracking for the month-end FX journal entry. Phase 1 holds FX wires in a visible state between the bank date and month-end close — 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

Phase 1 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

Phase 2: 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.

Phase 2 — batch write-back (more complex than 1-to-1)

Phase 1 value case — confirm with cash management team

Steps this replaces

Manual summation of bank and journal entries to verify $0.00 balance. Phase 1 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 at month end to record the FX conversion before reconciliation can be completed.

Possible anomalies

Failed Payment Duplicate Amount Variance

Amount Variance applies to FX wires only — expected due to currency conversion.

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 anomalies

Failed Payment Duplicate

Amount Variance on checks is not a confirmed scenario — a check amount is fixed at issuance. Flagged for cash management team confirmation.

Matthew Bender checks are processed differently and may not follow the standard check number matching model. Confirm with cash management team before reconciling these.

≈

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 anomalies

Failed Payment Duplicate

Matching field not confirmed. Question to ask: "Can you confirm whether Payment Reference Number is the matching field for EFTs, the same way it is for wires?"

←

Direct Debit

Citibank Credit Card · PA Supreme Court · RELX CENTRE CTA US (tx code 455)

How matching works

End-to-End ID

bank side (identifying label only)

? — matching field unconfirmed

GL side

unconfirmed

Vendor (Counterparty) used as the identifying label. The specific field used to match bank side to GL side has not been confirmed — no transcript basis for any particular field.

Normal workflow

Direct debits do not go through AP — they are posted as manual journal entries in the GL. The user identifies the debit on the bank side, locates the corresponding journal entry, and reconciles manually. End-to-End ID is long (16+ digits) and unique per transaction.

Possible anomalies

Failed Payment Duplicate

Matching field not confirmed. Question to ask: "When you reconcile a direct debit, what field on the bank side and what field on the system side are you matching on?"

↕

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 anomalies

Amount Variance

If batch totals do not balance to $0.00, there is a variance that must be resolved before reconciliation can complete.

Transaction code 575 meaning unconfirmed. Question to ask: "What does code 575 mean and how do you handle those entries — do they get reconciled separately?"