Skip to content

Settlement & Reconciliation

Money is only real once it has actually moved. Settlement is the confirmation that a payment truly happened; reconciliation is keeping Moria’s records and the external providers’ records in agreement. This page describes how both work — the assurance a partner’s finance team needs.

Money movements settle asynchronously and on confirmation, never optimistically:

  • Money in — a balance is credited only when the payment provider sends a signed confirmation that the money arrived. Until then the top-up sits pending; it never credits on request alone.
  • Money out — funds are disbursed to the provider, and the transaction is finalized on the provider’s confirmation callback.
sequenceDiagram
    autonumber
    participant App as Moria
    participant Prov as Payment provider
    App->>Prov: Initiate movement (in or out)
    Prov-->>App: Acknowledged, pending
    Note over App: No balance change yet
    Prov-->>App: Signed settlement confirmation
    App->>App: Post to ledger, update balance
    App-->>App: Transaction now final

Every settled movement is written to a double-entry ledger: each transaction posts balanced entries, so the books always add up. Fees are booked as their own entries — the provider fee and the platform margin sit on separate lines from the principal, each attributed independently. Balances can never go negative.

This gives a partner:

  • A bank-grade statement per member — dated entries with a running balance.
  • A receipt for every transaction.
  • Independent fee attribution — principal, provider fee, and margin each traceable.

Reconciliation — keeping records in agreement

Section titled “Reconciliation — keeping records in agreement”

Some movements confirm later than others (for example, certain money-out rails). Moria runs scheduled reconciliation that revisits pending items and settles them against the provider’s records, so nothing is left hanging in an unknown state.

flowchart TD
    A([Scheduled reconciliation run]) --> B{Any pending items?}
    B -->|No| Z([Books already agree])
    B -->|Yes| C[Check each against provider records]
    C --> D{Confirmed settled?}
    D -->|Yes| E[Finalize + post to ledger]
    D -->|Not yet| F[Leave pending for next run]
    E --> Z

    classDef step fill:#E8E1FF,stroke:#3C2C96,stroke-width:1.5px,color:#1E1B4B;
    classDef gate fill:#FFF3D0,stroke:#F4BE27,stroke-width:1.5px,color:#8B5A00;
    classDef done fill:#FDF8E8,stroke:#3C2C96,stroke-width:2px,color:#1E1B4B;
    class A,C,E,F step;
    class B,D gate;
    class Z done;

From the same ledger, a partner can obtain:

  • Member statements — the full transaction history, exportable.
  • Fee & margin reports — provider cost and platform margin, separated for revenue-share.
  • Reconciliation status — what has settled and what is still pending.
  • Statement & report delivery — the cadence and format your finance team needs.
  • Revenue-share reporting — margin attribution aligned to your agreement.
  • Access — which of your admins can pull financial reports.
  • A balance changes only after a confirmed, signed settlement — not on request.
  • Settlement timing depends on the external provider; reconciliation closes the gap.
  • Reporting reflects settled ledger state, so figures are always reconcilable.