Settlement exceptions for platforms

Unmatched settlements are not a report. They are a queue.

When money moves, something fails to match.

A refund lands without the original. A batch splits. A merchant ID is missing. Support opens a ticket. Finance waits on engineering.

If the only answer is “pull the processor portal,” you do not own the payment layer. The processor does.

What we put in place

An exceptions queue on your side:

Settlements and events with your business identifiers
A place to see what did not match
A path to resolve without rewriting the integration
Connector updates under a Run, so the next rail does not restart discovery

What this is not

Not a BI dashboard bolted onto a PSP export. Not us holding the funds while we “investigate.” Not a promise that exceptions disappear. They get owned.

Boundary

Futurify is an ISV. You keep the processor contract. We build and run the layer. Build is fixed price. Run is monthly per account — ask for the current ladder.

Named proof

Beniplus: about $1M a month through an integration and ledger we built. Manual EFT uploads to Zum Rails. Reconciled per member to the provider record. That is the bar for “matchable.”

Who this is for

You already have unmatched rows. Bring one real example to the first call.

Payment reconciliation for platforms — ledger, exceptions queue with named owner
Payment migrations and cutovers — migration scoping and day-one ownership