Traxpay is a Frankfurt-based payments processor serving mid-sized e-commerce merchants across the DACH region. The company processes card, SEPA and wallet payments through several PSPs and settles to merchants daily. Its finance team of six handled reconciliation across three banks, four payment providers and an internal ledger, mostly in spreadsheets. As volumes grew past 400,000 transactions a month, the close process became the slowest part of the business.

• 01

  Three days to close.

  Month-end reconciliation took the full finance team three working days, delaying reporting to management and auditors.

• 02

  Formats that never match.

  Each bank and PSP exported data in a different format, with different references, fee treatments and settlement timing.

• 03

  Unexplained exceptions.

  Mismatches were flagged but not explained, so each one needed manual investigation.

• 04

  Audit pressure.

  Auditors wanted a clear trail showing why every item was matched or written off.

We built a reconciliation agent that ingests daily files from every bank, PSP and the internal ledger, normalises them into one schema, and matches records using deterministic rules first and an LLM for the ambiguous remainder. For every match it cannot make with confidence, the agent writes a plain-language explanation (split settlement, fee deducted at source, duplicate refund) and proposes the next step. Finance reviews a short exception queue each morning instead of full spreadsheets. Every decision is logged with the rule or reasoning behind it, giving auditors a complete trail. The agent runs inside the client's AWS account, and no transaction data leaves their environment.

• Multi-source ingestion

  Automatic pulls from 3 banks and 4 PSPs via SFTP and API, normalised into one ledger view.

• Hybrid matching engine

  Rules handle clear matches, and the LLM handles partial, split and many-to-one cases.

• Explained exceptions

  Every unmatched item comes with a reason and a suggested action.

• Exception queue

  A review screen where analysts approve, reassign or override in one click.

• Audit trail

  A full log of every match decision, exportable for auditors.

1. 1

   Split settlements

   One PSP payout often covered hundreds of transactions minus fees. We built many-to-one matching with fee inference.

2. 2

   Data residency

   The client required data to stay in the EU. We deployed the model through an EU-hosted endpoint inside their AWS region.

3. 3

   Trust in AI decisions

   Finance was wary of automated matches. We added confidence scores and a shadow mode that ran for two weeks alongside manual work before going live.

1. Weeks 1–2

   01 Discovery

   Mapped every data source, fee rule and exception type with the finance team.

2. Week 3

   02 Design

   Designed the matching logic and the exception queue with analysts in the room.

3. Weeks 4–7

   03 Build

   Built ingestion, the matching engine and the review interface.

4. Weeks 8–9

   04 Shadow run

   Ran the agent alongside the manual process and tuned rules until results agreed.

5. Week 10 onward

   05 Launch & improve

   Went live for month-end close and added new PSPs through a monthly retainer.

The first live month-end close finished before lunch on day one. The finance team now spends its time on the 8% of transactions that need judgement rather than on copying data between spreadsheets. The audit that followed closed with no reconciliation findings, and the team absorbed a 30% rise in volume without new hires.