Revenue recognition

When a customer pays for service that hasn’t been delivered yet, the cash is deferred revenue — a liability — until the service is delivered. Paylera schedules deferred revenue across the service period and posts it to the ledger as it earns, so closing the books takes one call instead of a spreadsheet.

What gets deferred

Line item	Recognition
Subscription period (e.g. monthly plan, monthly billing)	Straight-line across the period.
Annual prepay (12 months billed up front)	Straight-line across 12 months.
One-off setup fee	Recognised immediately at invoice finalisation.
Usage-based line item	Recognised at the period close that produced it.
Discount line	Same recognition cadence as the line it discounts.
Tax	Liability, not revenue — never deferred.

The recognition rule is per-component and configurable on the plan:

{
  "code": "annual",
  "pricing": { "model": "flat", "amount": "1188.00" },
  "recognition": {
    "rule": "straight_line",
    "service_period_months": 12
  }
}

Available rules: straight_line (default), point_in_time, usage_based, milestone (with explicit milestone postings).

The schedule

When an invoice with a deferred line is paid, the revrec worker creates a recognition schedule. Each row in the schedule says “on date X, recognise Y of revenue.” A monthly straight-line example:

Period start	Period end	Amount to recognise
2026-05-06	2026-06-05	99.00
2026-06-06	2026-07-05	99.00
… (12 rows total)

Inspect a schedule:

GET /v1/invoices/{id}/recognition-schedule

Closing a period

Close a period to crystallise the recognition entries up to that date:

POST /v1/revrec/periods/close
{ "period_end": "2026-05-31T23:59:59Z" }

The worker walks every open schedule, finds rows whose period_end ≤ period_end, and posts them to the ledger:

Deferred revenue (liability)    99.00   debit
  Recognised revenue            99.00   credit

Once closed, a period is locked. New schedule rows for that period (e.g. late usage) are recognised in the next open period instead.

You can preview a close without committing:

POST /v1/revrec/periods/preview
{ "period_end": "2026-05-31T23:59:59Z" }

Refunds and credit notes

When you refund a paid invoice, the recognition schedule is adjusted in place:

• Already-recognised amounts are reversed in the next ledger period.
• Future schedule rows are deleted.

This keeps revenue and refunds in the same accounting period only when they actually occurred in that period.

ASC 606 and IFRS 15

Paylera’s recognition model follows the five-step ASC 606 / IFRS 15 contract structure: identify the contract, identify performance obligations, determine transaction price, allocate, recognise. The specifics of how to model your contracts (especially performance obligations and standalone selling prices) are out of scope here — talk to your auditor. The mechanism Paylera provides is the schedule + ledger posting; the policy is yours.

Reports

A few useful reports out of the box:

Report	What
GET /v1/reports/deferred-revenue?as_of=YYYY-MM-DD	Open deferred-revenue balance.
GET /v1/reports/revenue-recognized?period_start=…&period_end=…	Recognised revenue in a window, grouped by product, plan, or customer.
GET /v1/reports/revenue-waterfall?cohort_month=YYYY-MM	Cohort waterfall showing how a month’s contracts roll out.

Each report streams CSV; large windows are paginated by cursor.

Webhook events

Event	When
revrec.schedule_created	A schedule attached to a paid invoice.
revrec.schedule_adjusted	A refund or credit note changed a schedule.
revrec.period_closed	A close transaction committed.
revrec.period_close_failed	A close was attempted and failed (rare).

Common pitfalls

• Setup fees are usually point-in-time. Don’t straight-line them across the contract — most auditors will reclassify.
• Annual prepay with monthly billing: the invoice may be monthly, but if the contract is annual, the recognition rule should reflect that. Set it on the plan component, not on the invoice line.
• Refunds reverse recognition prospectively, not retroactively. Already-recognised revenue stays recognised; the offset posts in the next period.