Inspiration

Reconcile was inspired by a simple problem: as a business grows, payments can come from multiple sources such as M-Pesa, bank transfers, cards, and cash, while sales records may exist somewhere else. Matching those payments to the correct orders can become a repetitive and error-prone manual process.

What it does

We built Reconcile as a payment reconciliation platform for growing small businesses. Its goal is not to blindly match payments based on amount alone, but to evaluate multiple signals such as payment references, amount, customer phone number, and transaction timing. When there is enough evidence, Reconcile automatically matches the payment. When the evidence is unclear, it sends the transaction to a review queue instead of guessing.

How we built it

The project was built with Next.js, Express, TypeScript, PostgreSQL, and Prisma. We designed the backend around reliable financial processing, including integer-based money values, business data isolation, webhook idempotency, concurrency-safe payment allocation, an append-only audit trail, and HMAC-SHA256 webhook verification. The reconciliation scoring engine was implemented as a pure function so that the matching logic could be tested independently.

Challenges we ran into

One of the biggest lessons we learned was that financial systems require more than simply making the happy path work. A payment may be delivered twice, two orders may have the same amount, a payment may only partially cover an order, or multiple possible matches may exist. These cases forced us to think about database constraints, transactions, concurrency, idempotency, and explainability rather than treating reconciliation as a simple CRUD operation.

Accomplishments that we're proud of

The biggest challenge was designing matching logic that could automate useful cases without creating dangerous false matches. We addressed this by giving different signals different weights and using confidence thresholds. For example, an exact payment reference provides stronger evidence than an amount match alone. If the system cannot establish a sufficiently clear match, it deliberately asks for human review.

What we learned

Building Reconcile also taught us how closely backend engineering and business requirements are connected. Features such as audit trails, duplicate protection, and concurrency control are not just technical details in a financial product—they directly affect whether users can trust the system.

What's next for Reconsile

Our vision is to make payment reconciliation less of a manual bookkeeping task and more of an automated workflow: automate the obvious, explain the decision, and escalate the ambiguous.