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

Already reconciled. Nothing to write back.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.