Skip to content

The lifecycle, ledger, and reconciliation layer for recurring revenue.

Built for correctness beyond the happy path.

For teams accountable for recurring revenue outcomes — not just the code that charges. When billing gets messy (upgrades, proration, retries, refunds, disputes), you still need an explainable record.

Payment execution is handled through integrated providers; Reccurs manages the lifecycle, reconciliation, and operations around it.

Designed for auditability and controlled change.

A lifecycle trace diagram showing: Event, Normalized record, Ledger entry, Reconciliation status, and Exception.
EventNormalizedrecordLedgerentryReconciliationstatusExceptioninvoice.paid (provider)refund.processed (provider)Normalized recordLedger entryReason: mismatch

Proof you can explain — end to end

Reccurs produces an end-to-end trace you can actually follow: what happened, what was recorded, which rule applied, and why the state changed.

An example audit timeline with time, source, event, ledger effect, state change, and reason tags.

Audit timeline fragment

Illustrative example
TimeSourceEventLedgerStateWhy
10:02providerinvoice.createdrecordeddraft → invoiced
Rule applied (v1)
10:04providerinvoice.paidrecordedinvoiced → paid
Matched as expected
10:05providerrefund.processedrecordedpaid → refunded
Rule applied (v1)
10:06providerinvoice.paidignored — duplicate eventrefunded → exception
ExceptionDuplicate event ignored

This is how non-happy-path billing stays explainable.

Capabilities in operational order

Designed for finance and ops ownership: explicit rules, deterministic outcomes, and clear exceptions—without hiding history.

Normalize provider events

Convert provider-specific webhooks into a canonical lifecycle record you can reason about across providers and time.

Mapping snippet

Provider events
Normalized
invoice.paid
revenue.settled
refund.processed
revenue.reversed
View mapping example

Inputs are mapped into a stable event model so finance and engineering can share one lifecycle language.

Record immutable ledger entries

Write append-only entries that preserve history and support independent audit review.

Ledger entry (example)

entry_id
subscription
invoice
created_at
ldg_…7f
sub_…2c
inv_…91
10:04
See the rule

Reccurs avoids edits-in-place; corrections are new entries linked to the original decision.

Reconcile with explicit rules

Match lifecycle expectations against provider reality and label the result clearly every time.

Reconciliation status

MatchedPendingException
subscription sub_…2c → status: Exception (reason: mismatch)
View matching logic

Reconciliation is deterministic: each status is produced by an explicit, reviewable rule.

Explain every change

Each state transition includes a reason, a source, and a rule reference — so every change is explainable after the fact.

State transition

paidrefunded
reason: refundsource: provider
View rule reference

Every decision records which rule version applied so changes remain explainable over time.

Surface exceptions clearly

An exception queue designed for owners — finance, ops, and engineering: what broke, why it matters, and what to do next.

Exception queue (example)

subscription
type
reason
status
owner
sub_…2c
drift
mismatch
open
finance
sub_…9a
order
out-of-order
triage
ops
View workflow

Exceptions carry reason codes and ownership so the team can resolve with context, not guesswork.

Controls are product features

Because correctness, auditability, and recovery are core product behavior — not afterthoughts.

Audit trail

Every lifecycle change is traceable to an event, a rule, and a recorded outcome — even after the fact.

Immutability by default

History is preserved; corrections are explicit and reviewable.

Idempotency and duplicates

Duplicate events are handled deterministically and recorded as such — no hidden side effects.

Versioned reconciliation rules

Rules are explicit, versioned, and referenced by every decision — past and present.

Execution boundary and verification

Payment execution is handled through integrated providers. Reccurs records, explains, and reconciles what occurred — even when outcomes are delayed or out of order. KYC/verification is required for payment services, and requirements may vary by country, entity type, and channel.

Scope clarity

Reccurs does not replace your payment processor. It gives your team ownership of lifecycle visibility, reconciliation, and operational controls around recurring revenue.

How it works

Events may arrive delayed, duplicated, or out of order — the system is built to handle that.

1

Connect

Receive billing lifecycle events from integrated providers and your internal systems — as they happen.

Integration details

Events may arrive delayed, duplicated, or out of order. Integrations should assume asynchronous delivery and behave idempotently.

2

Normalize

Convert raw events into a canonical lifecycle record you can reason about.

Normalization rules

Mappings are explicit so the lifecycle remains stable even when providers vary in naming and timing.

3

Record

Write immutable ledger entries and state transitions — no edits in place.

Ledger behavior

Append-only recording supports audit review and controlled change without rewriting history.

4

Reconcile

Compare expected vs observed outcomes and assign a clear, deterministic status.

Matching logic

Reconciliation is deterministic and produces reason codes for exceptions, not ambiguous errors.

5

Operate

Work exceptions with clear ownership, notes, and an audit trail.

Exception workflow

Teams can triage, resolve, and leave context for future reviews and close processes.

What you gain

Outcomes you can rely on when billing doesn’t go as planned.

  • Explainable states: every status has a reason, a source, and a trace — no guesswork.
  • Clarity: a lifecycle you can explain without spreadsheets or ad-hoc investigations.
  • Controlled operations: changes are reviewable, auditable, and never hidden.
  • Finance–engineering alignment: a shared model, deterministic outcomes, and fewer ambiguous investigations.
  • Fewer manual checks: automation where rules are clear, exceptions where they are not.

Designed for teams that need to explain outcomes — not just produce them.

Request access

This is a private beta. We’ll follow up with onboarding steps and integration requirements if there’s a good fit.

This is a request for access. No account is created yet, and no billing occurs at this stage.

Policies coming soon (pending legal review). We’re keeping data collection minimal during beta.

We work closely with a small number of teams to ensure correctness and fit.

FAQs

Are events processed in real time?+

No. Events may arrive delayed, duplicated, or out of order; Reccurs is built to handle these conditions explicitly and record outcomes deterministically.

What happens if provider events arrive out of order or are duplicated?+

Reccurs applies explicit, versioned rules to normalize, record, and reconcile events. Duplicate or late events are handled deterministically and recorded as such.

Does Reccurs replace my payment processor?+

No. Reccurs does not execute payments; it provides lifecycle visibility, reconciliation, and operational controls around recurring revenue.

Do you guarantee outcomes or uptime?+

No. Reccurs avoids guarantees that depend on multiple systems, and focuses on explainability, auditability, and controlled operations when things don’t go as planned.

Is verification or KYC required?+

Yes. Verification is required to use payment services, and requirements may vary by country, entity type, and channel.

Is this available to everyone?+

No. Reccurs is currently in a private beta, and access is granted to a limited number of teams to ensure fit and correctness during onboarding.

Explain outcomes. Operate with control.