Custom reconciliation automation for e-commerce finance teams.

MatchPass does not provide bookkeeping. We work alongside your existing accountant or finance team.

We build the deterministic matching layer for recurring payout and clearing-account exceptions that survive your connectors. Your accountant keeps the accounting.

Is this a MatchPass problem?

Strong fit

Multiple payment gateways settling into the same accounts.
DTC plus wholesale, with orders and invoices in different systems.
Several systems that all have to agree before close.
Recurring clearing balances that survive every period.
Multi-currency settlement against a single base currency.
High refund and chargeback volume crossing period boundaries.
Standard connectors already configured, with substantial repetitive manual investigation remaining.

Poor fit

Simple Shopify Payments reconciliation.
General bookkeeping.
Tax work.
Catch-up books.
One-off cleanup with no recurring process behind it.

If your existing software already produces a clean close, keep using it.

What we do, and what we deliberately do not

MatchPass is reconciliation engineering. We build deterministic matching logic, rollup rules for bundled payouts, a reason-coded exception queue and a scheduled run, then document the whole thing and hand it over.

We do not do your bookkeeping, we do not classify transactions, we do not close your books and we do not replace your accountant. If you do not have an accountant, we are not a substitute for one.

This page is the e-commerce application of a broader service: turning recurring finance workflows into documented, checked processes. If you already work with an accounting firm, we are happy to work behind them or alongside them, whichever they prefer. The page for accounting firms explains how that works.

What a build looks like

Start with the E-commerce Fit Score or a short conversation about one workflow. If the pattern is genuinely mechanical and worth building, we propose a written scope with acceptance criteria and a fixed price.

A typical first build

See pricing

One recurring reconciliation workflow, one representative period and agreed sources (for example Shopify, PayPal, Stripe, Amazon, wholesale and bank)
Matching rules, a reason-coded exception list and a scheduled run
One person on your team reviews the short list of items that still need a decision
Documentation, handover and an agreed correction period
A one-time build with no mandatory retainer

E-commerce work uses the same price ranges as any other workflow, as a workflow pilot or a workflow implementation. See pricing for the ranges and proposed terms. All prices are USD plus applicable taxes and depend on the workflow.

Matching decisions are deterministic logic, not model output, and outputs go to a person for review before anything is treated as final.

When standard software is enough

Standard connectors are often the right solution for standard workflows. If the connector posts activity correctly and the clearing account returns to zero without investigation, there is nothing here worth building. Keep the software you have.

When custom automation may be justified

The case for a custom reconciliation layer depends on recurrence, not on frustration. It is worth looking at when the same exception patterns return every close, several sources have to agree before the balance resolves, and meaningful staff time goes into work that follows repeatable rules.

If you want a structured answer rather than an opinion, the Fit Score scores one workflow against recurrence, effort, source complexity, rule repeatability and portfolio reuse. It runs in your browser and takes a couple of minutes.

Is this a MatchPass problem?

What we do, and what we deliberately do not

What a build looks like

When standard software is enough

When custom automation may be justified

Not sure whether this workflow is worth automating?