RevRec brainstorm · Domain & architecture · RevRec ↔ AC boundary

17 — RevRec ↔ Accounting Central boundary

Status: design lock candidate
Locks: ADR 0006
External PRD: RevRec Premium / Accounting Central PRD (local copy used in design session)
Companion: 13-full-design.md

1. One-sentence split

RevRec calculates whether, how much, and when revenue/deferred/unbilled move under ASC 606.
Accounting Central turns those amounts (plus billing, cash, tax, etc.) into balanced double-entry journals, mapped to a COA, closable and exportable to an ERP/GL.

AC does not implement SSP, ratable schedules, or modification accounting.

2. Why unify-but-separate

Unify Separate
Same tenant, same source facts, same period calendar family Different invariants (allocation vs Dr=Cr)
Shared event log / ops platform Different schemas & release cadence
One close story for finance users Clear ownership when numbers disagree

Anti-pattern: two ETL dialects that drift (legacy Hotglue revenue files vs accounting files).

3. Processing chain

Chargebee (and adapters)
        ▼
   domain events
        ▼
 ┌──────────────┐         published amounts          ┌────────────────┐
 │    REVREC    │ ───────────────────────────────►   │      AC        │
 │ apply/recog  │   recognized, deferred Δ,          │ business event │
 │              │   unbilled Δ, adj Δ                │ → subledger    │
 └──────────────┘                                    │ → COA map      │
        │                                            │ → journals     │
        │ billing events (invoice/pay/CN)            │ → ERP export   │
        └───────────────────────────────────────────►└────────────────┘

PRD chain (AC view):
Source activity → Business events → Subledger (by role) → GL resolution → Journal entries → Export

4. What RevRec publishes (AC inputs)

Minimum contract (logical):

Fact Description
RecognitionFact tenant, period, contract/po dims, amount, currency, event_id, policy_id
DeferredMovement increases/decreases to contract liability
UnbilledMovement contract asset movements
AdjustmentFact PPA / CN overflow reverses / manual policy adj
PeriodCloseSignal period state ≥ RECOGNIZED / SOFT_CLOSED as required

Billing/cash events may be consumed by both (RevRec for identity checks; AC for AR/cash journals).

5. What AC owns (from PRD — retained)

See PRD §§3–8 for requirement-level detail; this design does not rewrite the PRD.

6. Close ordering

From PRD §8.2 (adopted):

  1. RevRec close locks recognition books for the period.
  2. AC close locks GL/subledger books; for Revenue and Tax event types, RevRec must close first.

Reopen: AC reopen does not silently rewrite RevRec schedules; RevRec reopen/PPA follows ADR 0005.

7. Shared platform options (tech)

Option Pros Cons Recommendation
A. Shared Postgres, dual schemas revrec_* / ac_* Simple ops, joint TX possible Careful module boundaries Default
B. Shared event log, two projectors Strong separation Eventual consistency UX Good at larger scale
C. Separate DBs + async bus Team autonomy Harder dual-run recon Later

Outbox from RevRec apply/recognize feeds AC ingestion regardless of option.

8. Smoke / validation

9. What we maintain going forward

Maintain in RevRec Next docs Maintain in AC PRD / AC eng docs
ASC 606 model, apply, recognize COA, JE templates, tax modes
Period state for recognition AC close gates per event type
Published fact schemas Export mappings to NetSuite/QBO/etc.
Policy ids affecting amounts Role→account resolution

When a feature needs both (e.g. unbilled toggle), RevRec owns calculation switch; AC owns whether/how it journals (PRD §9.5).

10. Explicit non-goals at this boundary