P-Card Reconciliation
Live appMatch every procurement-card charge to a purchase order, then settle it into Fusion
A rebuild of an Oracle procurement-card reconciliation application as a modern web app. It takes a monthly card statement, matches each charge to the purchase order behind it, lets cardholders clear anything the system could not match on its own, and then stages a single AP invoice and the supporting journal entries for Oracle Fusion. A manager sees every cardholder on a statement; a cardholder sees only their own charges. The auto-match engine follows the same priority rules as the original Oracle package — an exact purchase-order hit first, then a supplier-and-amount match, then a best-effort guess it will refuse to make when it is not sure.
Next.js · TypeScript · Prisma · Neon Postgres · Vercel
Open the app ↗The problem it solves
Reconciling a corporate procurement-card statement is slow, manual work. Someone has to tie each charge back to the right purchase order, chase down the ones that do not match, split charges across accounts, and then hand-build the invoice and journal entries that push it all into the financial system. The original tool did this inside Oracle APEX and PL/SQL, tightly wired to the customer's environment.
How it works
- 1
Pick a user to sign in. What you see depends on their role — a cardholder lands on their own charges, a manager sees every cardholder on the statement. This stands in for the original APEX login and user-role lookup.
- 2
The main working screen. One “Run auto-match” ties each charge to its purchase order and shows the running totals — matched, unmatched, and the variance still outstanding. Here a charge is expanded to show the exact purchase-order line it matched, with room to add accounting lines or supporting journals.
- 3
The manager roll-up. Every cardholder on the statement, what they still owe against it, and their submission status. When variances are cleared the statement locks, and the AP invoice and journals stage for Fusion from here. It will not lock while any charge still carries a variance.
- 4
The extracts — final P-Card report, an accrual report driven by purchase-order approval dates, and a sales-and-use-tax analysis. Each downloads as CSV.
Why it's useful
- →One click matches a whole statement — exact purchase-order hits, supplier-and-amount matches, and the charges that genuinely need a human, each labeled with why.
- →Cardholders clear their own exceptions and submit; the system refuses a submission while any charge still fails to balance.
- →Managers lock a finished statement, then stage one AP invoice and the supporting journals — “interfacing to Fusion” is a single status flip, no integration required.
- →Final P-Card, accrual, and use-tax extracts download as CSV, and role-based access keeps cardholders in their own lane.
Try it yourself
Sign in at the live demo with any of these logins to see how the app changes by role:
Marta DelgadoP-Card Manager — every cardholder on the statement, lock, invoice and journal staging, and reportsRay OkonkwoCardholder — three charges, two of which auto-matchCliff BarrosCardholder — charges the engine declines to guess, to match by handNina FaradayCardholder — a best-effort match and a disputed chargeDana WhitfieldAdministrator — users and profile options
A clickable prototype — pick any user to sign in, no password. All data is synthetic. Nothing connects to a real Oracle Fusion instance; “interface to Fusion” only flips a status so you can walk the full cycle.
What data you will see
- →One demo statement, CITI-2026-05, with nine charges across four cardholders totaling $6,549.
- →Purchase orders, suppliers, and card-user roles staged as fixed data — the same things the real integrations would deliver.
- →The statement is shaped so a single auto-match run exercises every branch: exact hits, supplier matches, declines, a disputed charge, and a partial overage.