Inspiration

A payment arrives, but it does not equal any single invoice. It may cover several invoices, include a bank fee, or deduct an early-payment discount after the deadline. For a finance team, matching the cash is only half the job: the deduction also needs an explanation.

We built SettleSum around that distinction. A payment can match mathematically while still containing money the customer may owe. Our starting users are accounts-receivable teams at B2B wholesalers and distributors.

What it does

SettleSum matches bank deposits to combinations of open invoices and explains every deduction down to the cent.

Users can build a custom case, import invoice and deposit CSVs, or explore a clearly labeled synthetic ledger. The engine evaluates full payments, valid early-payment discounts, expired discounts, documented short-pay claims and permitted wire fees.

Successful matches show the selected invoices, deduction states, an exact payment equation and a balanced draft journal. Users can export accounting CSVs, draft debit memos and an audit record containing the source inputs and their hash.

Unexplained payments remain exceptions for review. Accounting entries and debit memos are drafts; nothing is automatically posted or collected.

How we built it

We built a React interface using Vite and Tailwind CSS, backed by Python, FastAPI and Pydantic, and deployed it on Vercel.

Our multi-state branch-and-bound solver searches invoice combinations using integer-cent arithmetic. It prunes unreachable branches, ranks feasible explanations and returns alternatives. Payment dates determine discount eligibility, and each invoice can be applied only once within a reconciliation run.

Text and text-based PDF remittances support deterministic local parsing. Optional Gemini extraction is available when configured. The reconciliation calculation remains deterministic, and every generated journal must balance before it is returned.

Challenges we ran into

The central challenge was preserving the meaning of a deduction while finding an exact numerical match. The same discounted payment needs different accounting treatment depending on when it was received.

We addressed this through explicit invoice states, inspectable equations and separate accounting treatments. We also bounded the search: when its budget is exhausted, the engine returns a search-limit exception.

Custom-case entry and flexible CSV imports made it possible to test fresh inputs without depending on prepared sample transactions.

Accomplishments that we're proud of

Our synthetic benchmark reconciles seven of eight deposits, covering $87,982 in cash and identifying $164 in potentially recoverable expired discounts.

Changing a payment date can preserve the exact cash match while reclassifying a valid discount into recoverable receivables. These are computed demonstration results, not customer revenue or collected cash.

The project includes automated coverage for changed inputs, rounding, duplicate prevention, search limits and journal balance.

What we learned

Finance teams need an explanation they can inspect, a clear exception path and control over what happens next. Separating document extraction from financial calculation makes the system easier to verify.

Business model

We propose a subscription per business, beginning with a $99 monthly pricing hypothesis and higher-volume plans for accounting firms. Pricing is unvalidated; no paid plan is currently implemented.

We would begin with small pilots using exported wholesaler ledgers, then approach bookkeeping firms serving similar clients. We would measure review time, accepted matches, false allocations and disputed deductions actually collected before finalizing pricing.

What's next for SettleSum

Our next steps are customer validation, persistent workspaces, authentication, tenant isolation, configurable accounting policies and approval history.

Larger workloads would require background processing, improved candidate filtering and representative performance testing. The underlying search remains combinatorial.

Accounting connectors and a read-only MCP interface are future integration options. An assistant could request a payment explanation through the same deterministic engine, while posting entries and contacting customers would remain separately approved actions.

Today’s prototype is session-based: reloading clears browser-held records. Our immediate goal is to validate the workflow through a controlled pilot.

Built With

Share this project:

Updates

Submission history