Slevomat: order-to-cash and payment reconciliation connected to Salesforce.

The challenge

In high-volume e-commerce, money arrives from every direction: card payments through gateways, bank transfers, and refunds moving the other way. Every order should reconcile cleanly — an order, a payment, a bank or gateway record, an accounting entry. At scale, even a small percentage of exceptions turns into a large absolute number of unresolved items every single day.

The structural problem is fragmentation. The shop platform knows about orders, the payment providers know about transactions, the bank knows about settlements — and the CRM often knows about none of it. Finance ends up reconciling in spreadsheets, and customer-facing teams cannot answer the simplest operational question with confidence: has this order actually been paid?

Reconciliation at this volume is also never a one-to-one matching exercise. Gateways settle in batches with fees deducted, so a bank line rarely equals a single order. Refunds and partial payments break naive matching logic, and timing differences mean a payment can be real for days before it is visible in a settlement. Any design that assumes clean one-payment-per-order data fails in the first week of production.

That is the industry backdrop. The published scope of our work with Slevomat is specific: order-to-cash and payment reconciliation connected to Salesforce.

Our approach

Reconciliation projects start with following the money, so discovery meant mapping every flow that moves value — orders, payments and refunds across gateways and bank accounts — before designing anything. That mirrors how we run every build: discover, design, build, run, in tested increments rather than a big bang, with the senior engineers who scoped the work delivering it.

The design principle for matching at volume is to be deterministic first and honest about the remainder. Automation should clear the bulk of transactions using strict rules, and everything else should land in an explicit exception queue for a human — not silently mis-match. We described that philosophy in reconciling bank feeds without losing your mind: matching rules, exception queues, and the small share of items that always needs a person.

Delivery follows the same logic. The first increment gets one feed matched end-to-end in production, with the match rate measured honestly, before coverage widens to further feeds and flows. Exception handling is designed with the finance team, not for them — the people who resolve unmatched items daily know exactly which information a queue entry must carry to be resolvable in seconds instead of minutes.

Architecture, at pattern level

We publish client architectures at pattern level only — enough to show the shape of the build without disclosing internals.

Order-to-cash spine

The commercial lifecycle — order, payment expectation, settlement, refund — is represented in Salesforce so there is one place where the state of an order's money is visible. The reference shape is the one we documented in order-to-cash on Salesforce. Connecting this to the CRM is the point, not a convenience: payment state sits next to the customer conversation, so a support agent and a finance analyst are reading the same answer rather than querying different systems.

Feed ingestion

Bank and gateway feeds are ingested asynchronously. High-volume ingestion belongs in batch and event-driven patterns, not synchronous calls: imports are idempotent, so a replayed file or a repeated message never double-books a payment, and a failed run can be retried safely.

Matching and exceptions

Matching runs in tiers: exact-reference matches clear automatically, tolerant rules handle common variations, and the remainder goes to an exception queue with a full audit trail. The goal is not 100% automation; it is 100% visibility of what did and did not match.

Audit and close

Every automated match records why it happened — which rule fired, which references agreed — so a match can be defended months later, not just observed. Unmatched items age visibly rather than accumulating in the dark, which turns the financial close from a spreadsheet hunt into working a queue down to zero. Reconciliation that cannot explain itself has merely moved the problem, not solved it.

The productised pattern

This reconciliation pattern is the one we package as TransactionHub, our accelerator that pulls transactions from secure banking APIs and matches them to Salesforce records automatically — the same discipline, installable as a product.

Outcome

We do not publish client metrics without agreement, so the outcome here is stated qualitatively: the published scope — order-to-cash and payment reconciliation connected to Salesforce — gives one system a live view of orders and their payments, with automated matching doing the repetitive work and exceptions surfaced for people instead of buried in spreadsheets.

Related reading