Inspiration

Anyone who sells online knows the moment when your order records and PayPal transactions don’t line up. A payment seems to be missing, an amount is off by a few dollars, or a charge shows up twice. Timing gaps, refunds, fees, and retries all create differences that are hard to see from the outside. The hard part isn’t spotting the mismatch; it’s explaining it. Someone on the finance team ends up spending hours digging through exports and spreadsheets to trace what happened.

What it does

ReconcileIQ compares merchant orders against PayPal transactions and automatically surfaces discrepancies: missing payments, amount mismatches, and duplicate captures. For each discrepancy, AI examines the underlying evidence, explains the likely causes, and recommends specific checks to resolve it. The key design principle is that AI never makes financial decisions. It explains and suggests, and humans review and approve every next step. Every investigation is recorded in a complete audit trail. When reconciliation finishes, the team gets a place to input the review, comment after self-analysis, approve or reject the AI investigation, an email summary with a direct link to the detailed report.

How we built it

ReconcileIQ is built in two deliberately separate layers.

  1. A deterministic reconciliation engine. A rules-based engine matches merchant orders to PayPal transactions and classifies each discrepancy: missing payment, amount mismatch, currency mismatch, duplicate payment, unexpected payment, or reference mismatch. No AI is involved at this stage, so the facts are repeatable and testable.
  2. An AI investigation layer with a tightly engineered prompt. Each flagged discrepancy goes to the model with its evidence, and the prompt is built to make it an investigator, not a decision-maker.
    • The model is told what it can’t do. The engine has already classified the discrepancy. The model can’t re-decide it or judge whether a payment succeeded.
  3. The system computes facts, and the model copies them. Amount differences, capture IDs, and derived observations are calculated in code and passed in. We never ask an LLM to do arithmetic on money.
  4. Missing data is explicit. Absent fields appear as NOT PROVIDED, and the model is told that missing data is never a cause.
  5. Facts and hypotheses are kept apart. The summary may state only what’s in the evidence. Hypotheses go in a separate field, hedged with may or could, capped at two, and allowed only when they follow directly from the evidence. Otherwise, the model must say the root cause cannot be determined.
  6. Per-discrepancy guidance. Each status gets its own instructions and a format-only example, so a duplicate-payment investigation looks nothing like a currency mismatch.
  7. Structured JSON output. Every response has a summary, possible explanations, recommended checks, and requiresHumanReview, which is always true. There are no confidence scores, so a guess can’t pretend as certainty.
  8. Email summaries that close the loop. When reconciliation finishes, the team automatically receives an email with total orders, discrepancies, unexpected payments, and a direct link to the full report setup using Zapier. Analysts don’t have to remember to check a dashboard. The investigation comes to them.
  9. An audit trail. Every investigation is recorded, so reviewers can see what the model was given, what it returned, and what a human approved. Tech stack: Java, SpringBoot, React, TypeScript, PostgreSQL, AG Grid, Zapier, Render, PayPal Sandbox

Challenges we ran into

  • Recommendations that told analysts to re-read the screen. Early checks were things like “compare the expected and actual amounts,” which the report already shows. I added a rule that every check must point to a source outside the dataset, such as the PayPal dashboard or API, application logs, webhook logs, or customer records. I then wrote status-specific checks, so a missing payment sends the analyst to ingestion logs and a duplicate sends them to capture request logs.
  • Speculation that sounded like fact. The model was quick to blame fees, refunds, or currency conversion with nothing in the evidence to support it. I banned those from the explanations unless the data shows them, but still allowed them as things to verify in the recommended checks. That kept the useful leads without letting the model assert a cause. -Models copying examples. I added explicit rules that examples show format only, and that identifiers must be quoted exactly as supplied, never invented.
  • Keeping AI on the investigation side of the line. It’s easy for a helpful model to suggest refunding the duplicate. I forbade any recommendation to change, refund, void, or capture a payment, so the output stays advisory.

Accomplishments that we're proud of

  • A clean separation of detection and explanation. The facts never depend on a model’s guess, and the AI can’t change them.
  • A prompt that makes AI safe for finance work. It states only observed facts, hedges every hypothesis, admits when the cause can’t be determined, and never recommends financial action.
  • Investigation guidance that points somewhere new. Each discrepancy type produces checks tailored to that problem and aimed at external systems.
  • A complete audit trail built in from the start rather than added afterward.
  • An end-to-end workflow, from reconciliation to inbox. The team gets a place to input the review, comment after self-analysis, approve or reject the AI investigation, summary, and a direct link to reconciliation without lifting a finger.

What we learned

  • Learning PayPal’s sandbox from scratch. It was my first time using it, and working through orders, captures, and identifiers taught us how much real payment data depends on which fields are present, why the system must treat missing data as missing, never as a cause, and how to integrate the application with Zapier and hosting using Render.
  • Most prompt work was subtraction. The biggest gains came from narrowing what the model was allowed to say, not from asking it to be smarter. Every rule we added closed off a specific way the output could go wrong.
  • Give the model less to decide. When I computed facts in code (amount differences, capture IDs, derived observations) and passed them in, explanations became far more reliable than when the model had to work them out. Use code for arithmetic and AI for explanation.
  • Separate what’s observed from what’s guessed. Splitting the output into a fact-only summary, hedged hypotheses, and checks to verify made responses easier to review and much harder to misread as conclusions.
  • “I can’t tell” is a valid answer. Teaching the model to say the root cause can’t be determined from the evidence was better than letting it invent a plausible story. In finance, an honest gap beats a confident guess.
  • A good recommendation points somewhere new. A check is only useful if it sends the analyst to a source they haven’t already looked at, such as logs, the PayPal dashboard, or customer records, rather than repeating what’s on screen.
  • Examples are powerful, and risky. The model leans heavily on examples, so we had to state explicitly that they show format only and that identifiers must never be copied or invented.
  • In finance, trust beats cleverness. The most valuable thing AI can do here isn’t deciding; it’s explaining, and an audit trail is what makes that explanation defensible.
  • Notifications are part of the workflow. An accurate report nobody opens doesn’t help. The email summary with a direct link is what gets the right people to the right place at the right time.

What's next for ReconcileIQ

  • Log-aware investigations. Give the AI read-only, per-order access to application logs, PayPal API and transaction data, and webhook delivery logs. Instead of telling analysts to check whether a capture was retried or a webhook arrived twice, ReconcileIQ will check and cite the exact log entries as evidence. It still only explains, and humans still approve every next step.
  • Live PayPal data. Connect to PayPal’s Orders and Transaction Search APIs, and use webhooks to trigger reconciliation as events arrive, so there are no manual exports.
  • Wider PayPal coverage. Add refunds, disputes, chargebacks, fees, and settlement and payout matching, plus multi-currency conversion details.
  • Smarter notifications and feedback. Add severity-based alerts and digests to the email summary, and let analysts mark whether a recommended check helped so prompts improve over time.

Built With

Share this project:

Updates

Submission history