Deferred Revenue Schedules for Annual Subscriptions

An annual subscription is the canonical revenue-recognition problem because the gap between cash and earned revenue is at its widest: you collect twelve months of money on day one and then owe service for the next 364 days. The deferred revenue schedule is the artifact that bridges that gap — a row-by-row plan of how a single upfront payment is earned over time. This page sits under Revenue Recognition (ASC 606 / IFRS 15) and is the practical build: the exact arithmetic of straight-line daily recognition, the journal entries that post each night, how mid-term upgrades and refunds adjust an in-flight schedule, and what reconciliation has to prove at month-end close. You reach for this when finance asks why the deferred revenue line on the balance sheet does not tie to the sum of open subscriptions, and you need a schedule that is correct to the cent.

Trade-offs

The schedule’s granularity trades storage and audit clarity against proration precision. Monthly is auditor-friendly but coarse; daily materialized is exact but 365 rows; daily computed-on-demand keeps one header row with exact proration. The map ranks them.

Before writing code, decide the granularity and rounding policy of the schedule. The choices have real consequences for storage, audit clarity, and how cleanly mid-cycle changes prorate.

For most SaaS teams the sweet spot is a daily schedule computed from a single header row: storage stays flat at one row per contract, proration is exact, and you materialize entries only into the ledger as they are recognized. The examples below use that model.

A subtle decision hides inside the word “daily”: which day-count convention divides the total. A calendar-accurate schedule uses the real length of the service window — (service_end - service_start).days + 1, which is 365 for a normal term and 366 whenever the window straddles a February 29. Hardcoding 365 looks harmless until a leap-year contract recognizes one extra day it never had funding for, leaving a stranded cent of deferred balance that no nightly run will ever clear. The alternative, a 30/360 convention borrowed from bond markets, treats every month as 30 days and the year as 360; it makes monthly slices identical but produces obviously wrong per-day amounts for the 31st and for February, so avoid it for daily SaaS recognition. Anchor the divisor to the actual header dates and the schedule self-corrects for leap years, short first months, and any term length a sales team invents.

One more storage question decides itself once volume climbs: whether to keep the amount as an integer count of minor units or a DECIMAL. Integer cents with a carried remainder is the only representation that is closed under addition — 365 slices provably re-sum to the header total_amount — whereas a DECIMAL(12,2) column silently rounds each write and reintroduces the drift you were trying to kill. Store total_amount and recognized_amount as BIGINT minor units and reserve any decimal type for display formatting at the very edge of the system.

Step-by-Step Implementation

The five steps post the full amount to deferred, derive the per-day slice with remainder handling, recognize nightly, then adjust for upgrades and refunds. The balance-transfer diagram shows the invariant: deferred and recognized always sum to the invoiced total.

1. Post the invoice to deferred revenue

At finalization the entire annual amount becomes a liability. Nothing is revenue yet. In double-entry terms, you debit cash (or accounts receivable) and credit deferred revenue for the full invoiced total in cents.

-- $1,200.00 annual plan, billed upfront on 2026-01-01
INSERT INTO ledger_entries (ledger_entry_id, account, direction, amount, subscription_id, posted_at)
VALUES
  (gen_random_uuid(), 'cash',              'debit',  120000, '...', '2026-01-01T00:00:00Z'),
  (gen_random_uuid(), 'deferred_revenue',  'credit', 120000, '...', '2026-01-01T00:00:00Z');

The schedule header records the service window and the immutable original amount:

INSERT INTO rev_rec_schedules
  (schedule_id, subscription_id, invoice_id, service_start, service_end, total_amount, recognized_amount, status)
VALUES
  (gen_random_uuid(), '...', '...', '2026-01-01', '2026-12-31', 120000, 0, 'active');

2. Derive the per-day amount with remainder handling

Straight-line means equal recognition per day, but $120,000 cents over 365 days is $328.767…, which does not divide evenly. Use integer division and push the leftover cents onto the final day so the schedule sums to exactly $1,200.

def daily_amount(total_cents: int, day_index: int, days: int) -> int:
    base = total_cents // days
    remainder = total_cents - base * days   # cents that don't divide evenly
    # ✅ the last `remainder` days each get one extra cent
    return base + (1 if day_index >= days - remainder else 0)

# 120000 over 365 days -> base 328, remainder 280
# days 0..84 recognize 328c; days 85..364 recognize 329c; sum == 120000

Never recognize the remainder upfront or smear it with floating point — both leave a sub-cent drift that compounds across thousands of contracts into a visible balance-sheet discrepancy.

3. Recognize a day’s slice with a journal entry

The nightly job moves one day from the liability to the income statement. The journal entry is always the same shape: debit deferred revenue, credit recognized revenue.

def recognize_day(schedule_id: str, run_date: date) -> None:
    s = load_schedule(schedule_id)
    idx = (run_date - s.service_start).days
    days = (s.service_end - s.service_start).days + 1
    slice_cents = daily_amount(s.total_amount, idx, days)

    with db.transaction():
        # idempotency: UNIQUE(schedule_id, recognition_date) skips re-runs
        insert_rev_rec_entry(schedule_id, run_date, slice_cents)
        post_ledger_pair(
            debit="deferred_revenue",   # ⬇ liability shrinks
            credit="recognized_revenue", # ⬆ revenue earned
            amount=slice_cents,
            subscription_id=s.subscription_id,
        )
        bump_recognized_amount(schedule_id, slice_cents)

After day 85 of the example, recognized revenue is roughly $279.05 and deferred is roughly $920.95 — and they always sum back to $1,200.00.

4. Adjust for a mid-term upgrade

Say on day 100 the customer upgrades to a $2,400/yr plan and is billed a prorated upgrade charge for the remaining 265 days. You do not touch the 100 days already recognized. You close the old schedule at the boundary, recognize nothing retroactively, and open a new schedule for the new effective price across the remaining days.

def upgrade(schedule_id: str, change_date: date, new_remaining_invoice_cents: int) -> None:
    old = load_schedule(schedule_id)
    with db.transaction():
        # recognize through the day before the change, then close it
        complete_schedule(schedule_id, effective=change_date)
        # the prorated upgrade invoice funds a fresh schedule for the tail
        create_schedule(
            subscription_id=old.subscription_id,
            total_amount=new_remaining_invoice_cents,
            service_start=change_date,
            service_end=old.service_end,
        )

The still-deferred balance from the original plan plus the new prorated charge together fund the remaining 265 days. Because billing already prorated the cash side, rev-rec just mirrors the same effective date. The one trap here is double-funding: if billing credits the customer for the unused portion of the old plan and then bills the full new plan, the old schedule’s still-deferred balance must be reversed at the boundary rather than rolled into the new one, or you will carry the same 265 days of liability twice. Read the effective price of the change from the invoice that billing actually posted; never re-derive it inside rev-rec, because the two calculations will diverge on rounding and leave the deferred control account off by a cent per upgrade.

Downgrades and the no-negative-slice rule

A downgrade is the mirror image and is where naive schedules produce negative recognition. If the customer drops from $2,400/yr to $1,200/yr on day 100 with the difference issued as account credit rather than cash, the already-recognized 100 days stay recognized, and the remaining 265 days are re-based to the lower price. The remaining deferred balance may now exceed what the cheaper plan will earn over the tail; the excess is not revenue to claw back but a credit liability that moves to a customer-credit account, never a negative daily slice. Encode the invariant explicitly — every materialized slice_cents must be >= 0 — so a mispriced downgrade fails loudly at write time instead of quietly recognizing negative revenue that reverses a prior period.

5. Adjust for a refund

A cancellation with a refund on day 200 reverses only what is still deferred. The 200 days of service already delivered stay recognized — you earned them.

def refund_unearned(schedule_id: str, cancel_date: date) -> int:
    s = load_schedule(schedule_id)
    still_deferred = s.total_amount - s.recognized_amount
    with db.transaction():
        post_ledger_pair(
            debit="deferred_revenue",   # clear the remaining liability
            credit="cash",              # money returned to the customer
            amount=still_deferred,
            subscription_id=s.subscription_id,
        )
        mark_schedule_reversed(schedule_id, effective=cancel_date)
    return still_deferred  # ⚠️ never reverse recognized revenue

Verification & Testing

The schedule must prove three invariants: the daily slices sum exactly to the total, the job is idempotent, and deferred always equals total minus recognized — closing to zero at year end. Plus a month-end GL-to-schedule tie-out. The panel lists them.

The schedule has to prove three things: it sums to the invoiced total, the daily job is idempotent, and the deferred balance always equals total minus recognized. Test all three with a controlled clock.

def test_schedule_sums_to_total():
    total, days = 120000, 365
    s = sum(daily_amount(total, i, days) for i in range(days))
    assert s == total                              # not 119720, not 120280

def test_reconciliation_holds_every_day():
    setup_schedule(total=120000, start=date(2026,1,1), end=date(2026,12,31))
    recognized = 0
    for i in range(365):
        d = date(2026,1,1) + timedelta(days=i)
        recognize_day(SCHED_ID, d)
        recognized += daily_amount(120000, i, 365)
        assert deferred_balance(SCHED_ID) == 120000 - recognized
    assert deferred_balance(SCHED_ID) == 0          # fully earned at year end

For month-end close, the reconciliation query must show that the deferred revenue control account equals the sum of remaining schedule balances:

SELECT
  (SELECT balance FROM ledger_balances WHERE account = 'deferred_revenue')        AS gl_deferred,
  (SELECT COALESCE(SUM(total_amount - recognized_amount), 0)
     FROM rev_rec_schedules WHERE status = 'active')                              AS schedule_deferred;
-- gl_deferred MUST equal schedule_deferred; any delta is a recognition bug

The two example tests pin one contract, but the sum invariant is really a property that must hold for every plausible price and term, so it is worth exercising with property-based generation. Feed random total_amount values from a few cents up to a seven-figure annual contract, and random term lengths from 28 to 366 days, into daily_amount and assert the slices always re-sum to the total and that every slice differs from total // days by at most one cent. This catches the class of remainder bugs that a single $1,200 fixture will never reach — for example a $99,999-cent total over 366 days where the leftover is 363 cents and the tail-carry logic has to spread one extra cent across all but the first three days.

There is a second tie-out finance cares about that the daily invariant does not cover: the roll-forward. The deferred balance at the end of a month must equal the opening balance, plus everything billed into deferred during the month, minus everything recognized out of it, minus refunds and reversals. Reconciling that identity against the ledger’s movement entries — not just its ending balance — is what proves no entry was posted directly to the deferred control account outside the schedule. An out-of-band manual journal to deferred_revenue is the single most common reason the month-end tie-out passes on ending balance but fails on movement, and only the roll-forward surfaces it.

Gotchas & Production Pitfalls

The pitfalls are about time boundaries, rounding, and never un-earning revenue: UTC-versus-local day drift, float smearing, reversing recognized revenue, dangling deferred on cancel, and additive catch-up runs. The map groups them.

• Recognizing on a UTC boundary but billing in local time. If billing sets service_start from a local-midnight cutover and rev-rec runs at UTC midnight, the first and last day can be off by one, leaving a one-day fractional gap at year end. Pin both to UTC dates.
• Smearing the rounding remainder with floats. 120000 / 365 = 328.767... recognized as a float drifts a fraction of a cent per day. Across 100k contracts that is real money on the balance sheet. Always integer-divide and carry the remainder to the tail.
• Reversing recognized revenue on a refund. A refund only clears the still-deferred portion. Reversing already-earned revenue silently restates prior periods and will fail an audit — use a current-period contra-revenue entry if you must adjust a closed month.
• Letting cancellations leave a dangling deferred balance. If you stop the nightly job for a canceled subscription but never reverse the remaining liability, deferred revenue inflates forever. On cancel, recognize through the paid-through date, then explicitly reverse or roll forward the rest.
• Catch-up runs double-posting. A job that missed three nights must recognize all three missing days, not three copies of today. Drive recognition by recognition_date with a unique constraint so re-runs are exact, never additive.

Frequently Asked Questions

When does deferred revenue arise? As soon as cash is received for a service not yet delivered, which for an annual prepayment is the whole amount on day one. It releases across the service period rather than at invoicing.

Should the schedule be daily or monthly? Monthly is standard and sufficient for reporting. Daily precision adds rows without changing any reported figure, since periods close monthly.

What happens to the schedule if the subscription is cancelled early? Remaining deferred revenue is either released or refunded depending on the terms. Model the termination explicitly rather than letting the schedule run to its original end.

How is the schedule kept in step with billing? By generating it from the same contract and period data the invoice used, and asserting that the schedule for each obligation sums exactly to the amount invoiced for it.

Related

• Revenue Recognition (ASC 606 / IFRS 15)
• Invoicing & Credit Notes
• Building an Immutable Double-Entry Billing Ledger in PostgreSQL
• How to Calculate Prorated Charges for Mid-Cycle Upgrades
• Tax, Compliance & Revenue Recognition