Merchant advances

The quickest way to turn a receivables purchase into a lending problem is to describe it like a loan. So a merchant advance is modeled apart from installment credit: it buys a defined amount of future receivables for an agreed purchase price, no nominal rate is used to manufacture a fixed payment schedule, and projected completion is never dressed up as contractual maturity. A merchant who has been shown a forecast date as though it were a maturity date has been told something the agreement does not say.

Five quantities that must stay distinct

Collapse any two of these into one and the contract stops describing itself:

Product configuration may also define reporting frequency, reconciliation tolerances, permitted sales sources, minimum-remittance or reconciliation provisions, grace windows, and breach responses. Those terms are explicit fields. Inferring any of them from the projected duration would let a forecast quietly become an obligation the merchant never agreed to.

Only funding makes an agreement active

A submitted payout is not enough; the purchase price posts when the rail confirms release of funds. Likewise, a sales report does not reduce the balance until its remittance settles and posts. Both rules protect the same figure: a remaining purchased amount that moved on intentions rather than money would tell a merchant they had delivered more of the agreement than they had.

A report calculates; a remittance settles

Northstar reports $11,875.40 of settled card sales for September 8–9. The contract applies a 12% remittance rate.

raw remittance      = $11,875.40 × 0.12
                    = $1,425.048
posted remittance   = round($1,425.048, 2)
                    = $1,425.05
remaining purchased = $60,000.00 − $1,425.05
                    = $58,574.95

The request records the sales window, source, gross settled sales, exclusions, adjustments, and provider report identifier. The response preserves the unrounded intermediate value and the rounding policy used to reach the posted amount, so a half-cent disputed a year later is settled by reading what was stored rather than by re-deriving it under whatever policy is current then.

POST /v1/merchant-advances/ma_northstar_6N8Q/sales-reports
Idempotency-Key: northstar-2026-09-09-v1

{
  "periodStart": "2026-09-08",
  "periodEnd": "2026-09-09",
  "currency": "USD",
  "settledSales": "11875.40",
  "source": "processor_report",
  "sourceReference": "settlement_884210"
}

{
  "salesReportId": "msr_91DC",
  "status": "accepted",
  "calculatedRemittance": "1425.05",
  "remainingPurchasedAmount": "60000.00",
  "nextAction": "collect_remittance"
}

The remaining amount is still $60,000 in this response because the report has calculated an obligation but has not yet settled money. The balance becomes $58,574.95 after the related remittance reaches POSTED.

Projected amortization is a forecast

LendEasy maintains a projected schedule so operators can see expected completion and emerging drift. The schedule consumes a sales forecast; it does not create fixed installments.

When actual sales arrive, the projection is regenerated from the posted remaining amount. Prior forecast versions remain addressable for audit and model-performance analysis.

Missing sales are unavailable, never zero

Each reporting period is reconciled across three records:

1. the merchant or processor’s settled-sales report;
2. the remittance intent and payment-rail settlement; and
3. the posted ledger allocation.

Missing data is represented as UNAVAILABLE. Recorded as zero it would read as a merchant who sold nothing all week, and a processor outage would trigger precisely the collection response that a reporting failure must not. Instead LendEasy can place the agreement in REPORTING_REVIEW, suspend automated collection, and open a case without declaring a breach. A breach requires a configured rule and the facts that rule names.

Every evaluation stores the facts it used

Near-breach indicators are forward-looking: declining report freshness, remittance variance, repeated collection failures, or a projected completion date outside policy. Breach rules are contractual and versioned, and a breach argued in a year’s time is argued from what the rule saw at the time, not from what the same rule would say today:

• the rule and agreement version;
• the facts, source, and asOf time used;
• the outcome and next allowed actions; and
• any human approval or override.

The servicing workspace can route a merchant-support workflow, request corrected reports, revise a permitted remittance arrangement, or escalate for legal review. It cannot fabricate sales, silently turn a forecast into a fixed payment, or collect more than the remaining purchased amount.

Seven events, each with one job

Every route lives under merchant-advances

Nothing here is a loan route with a commercial flag set on it:

• POST /v1/merchant-advances creates an application.
• POST /v1/merchant-advances/{advanceId}/approve records the governed decision.
• POST /v1/merchant-advances/{advanceId}/funding-intents initiates the purchase-price payout.
• POST /v1/merchant-advances/{advanceId}/sales-reports records verified sales.
• POST /v1/merchant-advances/{advanceId}/remittances initiates or records a remittance.
• GET /v1/merchant-advances/{advanceId}/projection returns the versioned forecast.
• GET /v1/merchant-advances/{advanceId}/reconciliation explains source-to-ledger differences.