Skip to main content

Key concepts

This page explains ideas that appear across buyer and seller journeys. It avoids implementation specifics (exact rails, chains, or timings).

Buyer balances: available versus collateral​

Buyer-side money is organised so finance teams can see what is free to use versus what backs approved obligations.

  • Available balance: funds the buyer can use with more flexibility, including early settlement when that is allowed by configuration and cash position.
  • Collateral balance: funds that back approved seller obligations—often with a notion of free, used, and utilisation so teams can see how much capacity remains for new approvals.

In practice, Expereon does not replace the regulated custody of cash: buyer balances are shown in relation to connected payment providers or banks per supported currency. The platform surfaces balances, movements, and history so you can act (deposit, withdraw, transfer between available and collateral where permitted) with clear visibility.

Invoices and the collaborative loop​

An invoice is the finance object that ties a booking (or batch of bookings) to an amount the buyer will approve and pay. The default path is automation: booking reports submitted through the API—from buyer or seller systems, depending on how your programme is wired—are turned into invoices automatically, so operations and treasury work from the same reservation truth instead of retyping it.

Manual creation, CSV bulk upload, and adjustments still exist for edge cases, but day-to-day volume is designed around API-driven booking → invoice.

Typical stages (names may vary slightly in the product UI):

  1. Booking intake — structured booking data arrives via API; the system creates or updates draft invoice material from that feed.
  2. Ready for buyer action — invoice awaits review, clarification, dispute, or approval (or passes straight through auto-approval when rules allow).
  3. Approved — buyer has accepted the obligation under chosen payment source rules (for example collateral-backed versus available-balance paths).
  4. Pending settlement — obligation is due for settlement according to terms; automation or user action may apply depending on configuration.
  5. Paid or terminal failure states — includes outcomes such as paid, cancelled, or overdue-style states when deadlines pass without successful settlement.

Both sides need visibility into status transitions and auditability for finance, including a clear line from booking identifiers on each invoice back to the API payload that produced it.

Approval, trust, and automation​

Trust modes let a buyer organisation decide how much human review is required before invoices become binding obligations.

  • Manual approval: staff review each invoice; suitable when relationships or amounts demand tight control.
  • Auto-approval: invoices below configured thresholds (and within periodic caps) can be approved automatically, with the ability to pause automation when markets or counterparties change.

Trust settings can be tuned per seller where the product allows it, reflecting that not all partners carry the same risk profile.

Settlement and timing​

After approval, when money moves depends on payment terms, which balance source was selected, and whether the buyer chooses early settlement. Some paths are scheduled (for example aligned with due dates), while others may settle when the buyer explicitly pays from available funds.

Failed settlement attempts are expected to surface clearly, with retries or remediation paths rather than silent loss of state.

Disputes and refunds​

Disputes capture disagreement on an invoice before or after payment, with both parties able to present information and, if needed, platform mediation for unresolved cases.

Refunds describe a structured request and review flow when a booking is cancelled or adjusted: the buyer requests, the seller reviews, and approved refunds are executed by the system according to policy.