Skip to content

Brown Tab B002 — Ledger & Interest Methodology — Three-Period Framework

GUARDRAIL: BROWN — RENT RESTITUTION

Rent restitution and statutory remedies. No enterprise multipliers, no G21 tort.

POSTURE NOTE — Ledger & Interest Methodology

Brown calculates rent restitution claims for the 27-year period of illegal rent collection (1998–2025) — the dedicated recovery framework for unlawful rent. This document does not establish pattern doctrine (Yellow B001), calculate G21/Freeman damages (Blue/Red), implement settlement execution (Pink), or develop negotiation strategy (Purple). For pattern doctrine foundation see Yellow B001; for enterprise multipliers see Yellow B002; for other damages see Blue/Red; for strategy see Purple.

I. Document Role & Scope

I.A Role of B002 in Brown Volume 04

Brown B002 is the accountant-facing "how to do the math correctly" tab for rent restitution. It sits between:

  • B001 — Legal Framework & Fact Foundation (doctrine + Three-Period facts), and
  • B003 — Recovery Scenarios & Damages Bands (attorney-facing recovery ranges).

B002 answers:

"Given the Three-Period rent totals and repayment lanes in B001, how do we structure the ledger and compute 9% interest in a way an accountant, court, or opposing expert can follow?"

I.B What B002 Does

B002:

  • Defines the ledger structure (per payment / per year) for Christian's paid-rent stream (October 2001 – November 2019).
  • Specifies 9% simple interest methodology under CPLR 5001–5004, on a per-payment basis.
  • Distinguishes full-period context vs SOL-filtered schedules.
  • Enforces separation between:
  • Principal base: rent dollars actually paid (the recoverable "P"), and
  • Interest component: additional dollars generated by time-value and delay (the "I").
  • Provides standard templates and naming rules so multiple runs stay comparable and expert-auditable.
  • Defines a separate Invoice/Demand Log template for post-cessation conduct (Period 4).

I.C What B002 Does Not Do

  • Does not argue legal theory (see B001).
  • Does not choose a remedy theory (restitution vs. RICO vs. GBL §349) (see B001/B003).
  • Does not present final recovery bands (see B003).
  • Does not discuss enterprise multipliers, 4x–8x, or 10x–20x (Yellow/Pink only).
  • Does not define litigation strategy or settlement posture (see D001).

B002 is intentionally dry and mechanical — it is a calculator design document.

II. Inputs & Canonical Base Figures (From B001 v2.2)

II.A Three-Period Framework — Canonical Principal Band

From Brown B001 v2.2 (Three-Period Christian paid-rent analysis), the canonical figures are:

Period Duration Total Rent Band
Period 1 (P1): Oct 2001 – Oct 2008 ~7 years $67K–$118K
Period 2 (P2): Oct 2008 – June 2012 ~3.7 years $53K–$71K
Period 3 (P3): June 2012 – Nov 2019 ~7.5 years $126K–$225K
TOTAL ~18 years $268K–$394K

Key Boundary Dates:

Date Event Ledger Significance
October 2001 Christian's tenancy begins Start of payment period
October 21, 2008 Caldwell appellate ruling (APC / MDL §302 notice; see B001) P1/P2 boundary
June 1, 2012 Owner-stated Loft Board registration date (confirm via Loft Board file/FOIL) P2/P3 boundary
November 2019 Rent cessation (attorney advice) End of payment period

Guardrail rule: B002 does not change the canonical band. It only shows how to break it into evidence-backed ledger rows and apply interest.

II.B Evidence Sources (High Level)

Ledger inputs must be backed by:

  • Bank statements / checks / wire receipts
  • Lease documents / rent notices / invoices
  • Landlord accounting records / rent rolls (if produced)
  • Administrative and DOB/CO posture records (to establish illegality / coverage posture) — housed and indexed in C001

Each ledger row must be evidence-backed via a stable evidence reference.

III. Ledger Structure — Per-Payment Data Model

III.A Row-Level Unit: One Payment = One Row

The atomic unit of the rent ledger is a single payment actually made. Each row represents one rent payment made by Christian during the unlawful occupancy period.

Required columns (minimum):

  1. Row_ID — unique internal identifier (e.g., RR-YYYY-MM-SEQ)
  2. Payer — Christian Gray
  3. Unit — G21
  4. Payment_Date — date funds left payer and reached landlord (or best evidence-supported proxy)
  5. Period_Tag — P1 (Oct 2001–Oct 2008), P2 (Oct 2008–June 2012), or P3 (June 2012–Nov 2019)
  6. Rent_Month — the month the payment corresponds to (if known)
  7. Principal_Paid (P) — dollar amount of that payment
  8. Evidence_Ref — White WT / Bates or bank-statement citation
  9. Accrual_Start_Date — default = payment date (CPLR 5001(b) itemized approach)
  10. Interest_End_Date — date through which interest is calculated (see Section IV.C)
  11. Days_Outstanding — exact day count between start and end
  12. Interest_9pct (I) — calculated via 9% simple interest (Section IV)
  13. Total_P_plus_I — P + I
  14. SOL_Flag — Included, Excluded, Flagged (payment-level status; see Section V)
  15. Include_FP — boolean for Full-Period schedule
  16. Include_UE_SOL — boolean for Unjust Enrichment schedule
  17. Include_RICO_SOL — boolean for RICO schedule

III.B Period / Yearly Aggregation (Integrity Checks)

Each ledger must be aggregatable by:

  • Year, and
  • Period (P1, P2, P3).

Recommended year-level summary fields:

  • Year
  • Number of payments
  • Total principal for year
  • Total interest for year (under the chosen end date)
  • Total P + I
  • SOL posture summary for that year

Period Summary Table (required in each schedule):

Period Years Payment Count Principal Total Interest Total P + I Total
P1 (Oct 2001 – Oct 2008) ~7 [count] [sum] [sum] [sum]
P2 (Oct 2008 – June 2012) ~3.7 [count] [sum] [sum] [sum]
P3 (June 2012 – Nov 2019) ~7.5 [count] [sum] [sum] [sum]
TOTAL ~18 — $268K–$394K — —

These roll-ups are used to cross-check against the canonical band and to feed B003.

III.C Handling Missing Payment Granularity (Conservative Assumptions)

If monthly-level payment data is incomplete, B002 permits a conservative "annualized" proxy only if:

  1. The proxy method is explicitly described in Metadata;
  2. Each annualized figure is backed by evidence (e.g., bank-year summaries);
  3. A separate Assumption_Flag column identifies rows that are not single-payment true rows; and
  4. A clean audit path exists to replace proxy rows with atomic rows as evidence is filled in.

Default expectation: one payment = one row, unless lack of evidence forces a proxy.

III.D Separate Log for Post-Cessation Invoices (Period 4) — Conduct Context Only

B001 v2.2 distinguishes post-cessation activity (November 2019 – present) as invoicing/demands where no payments were made. This is not principal paid, but it may support:

  • RICO pattern continuity (mail/wire transmissions), and
  • Deception/harassment narrative.

B002 therefore defines a separate Invoice/Demand Log template (not a rent-paid ledger):

Required columns (Invoice Log):

  1. INV_Row_ID — unique identifier (e.g., INV-YYYY-MM-SEQ)
  2. Recipient — Christian Gray
  3. Unit — G21
  4. Invoice_Date — date invoice/demand issued
  5. Invoice_Period_Tag — P4 (Nov 2019–present)
  6. Amount_Demanded — dollar amount demanded
  7. Medium — mail, email, portal, hand-delivered, etc.
  8. Evidence_Ref — White WT / Bates reference
  9. Notes — e.g., "threatened action," "late fees," "collection warning"

Important: Invoices are not treated as "automatic predicates." Each invoice/demand may constitute a mail/wire transmission in furtherance of a scheme, subject to proof of deception/intent/materiality under the elected theory.

Guardrail: Period 4 Invoice Log totals are never added to principal paid. They are maintained separately as conduct context for pattern and notice arguments.

IV. 9% Simple Interest Methodology (CPLR 5001–5004)

IV.A Interest Basics — Statutory Authority

For New York prejudgment interest:

  • CPLR 5001(b) permits computing interest from the earliest ascertainable date the cause of action existed; where damages are incurred at various times, interest may be computed upon each item from the date incurred (the itemized approach used here).
  • CPLR 5004 (N.Y. C.P.L.R. § 5004 (McKinney)) sets the general statutory rate at 9% per annum (simple), except where otherwise provided by statute.

B002 does not argue entitlement; it assumes B001 has established the basis for interest and the appropriate accrual posture.

Note: CPLR 5004 provides for 2% interest in an action arising out of a consumer debt where a natural person is a defendant; this exception does not apply to tenant restitution claims against landlords for illegally collected rent.

IV.B Per-Payment Formula (Itemized Method)

For each payment row, compute:

Interest (I) = P × 0.09 × (Days_Outstanding ÷ 365)

Where:

  • P = principal amount of that payment
  • Days_Outstanding = (Interest_End_Date − Accrual_Start_Date), in days

Implementation rule: Use exact calendar day counts (including leap years) via spreadsheet date functions or accountant toolchain.

Example (illustrative only):

  • Rent payment P = $1,400
  • Paid on: January 1, 2010 (Period 2)
  • Interest End Date: January 1, 2026
  • Days Outstanding ≈ 16 years × 365 = 5,840 days

Then:

  • Years = 5,840 ÷ 365 = 16
  • Interest = $1,400 × 0.09 × 16 = $2,016
  • Total row = $1,400 (P) + $2,016 (I) = $3,416

Real implementations must use exact calendar day counts.

IV.C Choosing the Interest End Date (Schedule Metadata)

Counsel must select and document the interest end date. Standard options:

  1. Filing-Date Schedule — interest through the filing date of the rent-restitution complaint.
  2. Judgment-Date Schedule — interest through a hypothetical or actual judgment date.
  3. Cut-Off Schedule — interest through a standardized cut-off (e.g., 12/31/2026) for comparability.

B002 requires each ledger workbook to state prominently:

  • Interest end date, and
  • Schedule label (e.g., "Interest through 12/31/2026 — illustrative").

IV.D Single Intermediate Date Alternative (Optional)

CPLR 5001(b) permits use of a "single reasonable intermediate date" where damages were incurred at various times. B002 defaults to itemized per-payment interest for auditability, but allows counsel to elect:

  • SID Schedule (Single Intermediate Date) as an alternate run, documented in Metadata.

If SID is elected, the Metadata sheet must specify:

  • The chosen intermediate date and rationale
  • Label: "SID Schedule — [Date] — Alternative Method"

IV.E Treatment of Tolling & SOL in Interest

While B001 handles SOL analysis and tolling doctrine, B002 defines mechanics:

  • Interest computations are agnostic to whether a payment is ultimately recoverable under SOL.
  • Ledger rows for SOL-expired payments may still be computed (for context) but must be flagged and optionally excluded from "recoverable total" columns in SOL-filtered schedules.

V. SOL-Filtered vs Full-Period Schedules (Mechanics Only)

V.A Schedule Types (Standardized)

B002 standardizes these schedule types for the paid-rent ledger:

  1. FP — Full Paid-Rent Stream Context Ledger
  2. Includes all paid-rent rows (October 2001 – November 2019).
  3. Computes P, I, and P+I for every row, regardless of SOL.

  4. Label: "Full Paid-Rent Stream Context — Not All Amounts Recoverable"

  5. UE_SOL — Unjust Enrichment SOL-Filtered Ledger (6-year lookback)

  6. Filters paid-rent rows to those within a 6-year window (subject to tolling/discovery posture as elected in B001).

  7. Label: "SOL-Filtered — Unjust Enrichment (6-year window)"

  8. RICO_SOL — Civil RICO SOL-Filtered Ledger (4-year lookback)

  9. Filters paid-rent rows to those within a 4-year window (subject to accrual/discovery posture as elected in B001).
  10. Label: "SOL-Filtered — Civil RICO (4-year window)"

Optional variants (only if counsel elects):

  • GBL349_SOL — 3-year overlay schedule (Note: GBL §349 amendments effective February 17, 2026 — verify current provisions before filing)
  • COVID_TOLL — schedules incorporating fixed toll offset (~228 days, if adopted)

Separate from paid-rent schedules: Period 4 Invoice/Demand Logs are maintained as "Conduct Context" and are never added to paid-rent principal totals.

V.B Column-Level Handling of SOL

Each payment row should include:

  • SOL_Flag — e.g., Within_UE_6yr, Within_RICO_4yr, Outside_Both
  • Inclusion booleans for each schedule:
  • Include_FP
  • Include_UE_SOL
  • Include_RICO_SOL

Totals are computed by summing only where the relevant inclusion flag is TRUE.

V.C Reporting Totals (Per Schedule)

For each schedule type, report:

  • Principal_total
  • Interest_total
  • Total_P_plus_I
  • Number_of_payments
  • Average_age_of_payments (optional)

These totals feed forward to B003 and (if integration mode) to Pink as a base component.

V.D COVID-19 Toll Impact

The COVID-19 toll period (~228 days, March–November 2020) may extend SOL cutoffs. Ledger implementations should:

  • Note the toll in Metadata
  • Provide variant schedules with toll-adjusted cutoffs if counsel requires

VI. Principal vs Interest Separation (Guardrails)

VI.A Do Not Blur P & I

Every ledger or schedule must clearly separate:

  • Principal base (P) — rent dollars actually paid, evidence-backed
  • Interest (I) — time-value growth at statutory rate
  • Total (P + I) — reported but never used as a "multiplier base"

Rules: 1. Separate columns for P, I, and P+I. 2. Separate totals for principal and interest. 3. Narrative clarity: always state "$X principal + $Y interest = $Z total." 4. Never describe (P+I)/P as a "multiplier" in Brown.

VI.B Relationship to Canonical Band

  • The principal component of the FP paid-rent ledger should land within the canonical band $268K–$394K (subject to evidence refinement).
  • Any deviation must be explainable by evidence corrections and documented in Metadata.

VI.C Multiplier Guardrail

B002 does not apply:

  • 4x–8x enterprise multipliers (Yellow/Pink)
  • 10x–20x high-ratio bands (Pink appendix only)
  • RICO treble (3x) — that is B003's job to present as a scenario, not B002's to compute

B002's sole enhancement to principal is 9% interest. Any trebling or multiplying happens downstream.

VII. Template Standards & Naming Conventions

VII.A File-Level Naming

Recommended naming pattern for ledger workbooks:

  • BROWN_B002_LEDGER_FP_YYYYMMDD.xlsx — Full-Period Context
  • BROWN_B002_LEDGER_UE_SOL_YYYYMMDD.xlsx — Unjust Enrichment 6-year window
  • BROWN_B002_LEDGER_RICO_SOL_YYYYMMDD.xlsx — RICO 4-year window
  • BROWN_B002_INVOICE_LOG_P4_YYYYMMDD.xlsx — Period 4 Invoice/Demand Log

Where YYYYMMDD is the run date.

VII.B Tab-Level Naming (Within Workbook)

Paid-Rent Ledger Workbook:

  • FP_Ledger_Detail
  • UE_SOL_Ledger_Detail
  • RICO_SOL_Ledger_Detail
  • Summary_By_Year
  • Summary_By_Period
  • Metadata

Invoice Log Workbook:

  • P4_Invoice_Log
  • Metadata

The Metadata sheet should record:

  • Interest end date
  • Filing date assumed
  • SOL assumptions (including any COVID toll offsets)
  • Source evidence set (e.g., which WT tabs, which bank accounts)
  • Person who ran the ledger and date/time
  • Period boundary dates (Oct 2008 Caldwell; June 2012 Loft registration)
  • SID election (if applicable)

VII.C Column Names (Copy-Paste Ready)

Paid-Rent Ledger Detail Columns:

  1. Row_ID
  2. Payer
  3. Unit
  4. Payment_Date
  5. Period_Tag
  6. Rent_Month
  7. Principal_Paid
  8. Evidence_Ref
  9. Accrual_Start_Date
  10. Interest_End_Date
  11. Days_Outstanding
  12. Interest_9pct
  13. Total_P_plus_I
  14. SOL_Flag
  15. Include_FP
  16. Include_UE_SOL
  17. Include_RICO_SOL
  18. Assumption_Flag (optional — for proxy rows)

Invoice Log Columns:

  1. INV_Row_ID
  2. Recipient
  3. Unit
  4. Invoice_Date
  5. Invoice_Period_Tag
  6. Amount_Demanded
  7. Medium
  8. Evidence_Ref
  9. Notes

VIII. Integration with B003, C001, and D001

VIII.A Hand-Off to B003 — Recovery Scenarios & Damages Bands

B003 draws directly from B002 schedule summaries:

  • Principal_total_FP, Interest_total_FP, Total_FP
  • Principal_total_UE_SOL, Interest_total_UE_SOL, Total_UE_SOL
  • Principal_total_RICO_SOL, Interest_total_RICO_SOL, Total_RICO_SOL
  • Period-level breakdowns (P1, P2, P3)
  • (Optional) P4_Invoice_Count, P4_Total_Demanded (conduct context only, not principal paid)

B002 does not narrate bands; it provides the math spine.

VIII.B Coordination with C001 — Evidence & Expert Requirements

C001 scopes the forensic accountant engagement and evidence-gathering tasks. B002 should be attached as the technical appendix to any accountant instruction memo to eliminate ambiguity about interest computations and schedule taxonomy.

VIII.C Role in D001 — Strategy & Templates

D001 references B002 as the source of schedule templates and should include model "without prejudice" payment language for any pendente lite payment posture, consistent with counsel's elected procedural strategy.

IX. Attorney-Facing Summary (Plain English)

Plain-English Summary:

Brown B002 tells the accountant exactly how to turn Christian's paid-rent stream (October 2001 – November 2019) into court-ready ledgers with 9% simple interest. Every payment is a row, backed by evidence. Interest runs from each payment date to a defined end date at the statutory rate, and the same rows can be filtered into SOL variants (6-year unjust enrichment; 4-year RICO), depending on counsel's elected accrual and tolling posture.

The key guardrail is separation: principal ($268K–$394K) stays distinct from interest (which can push totals significantly higher depending on dates). B002 does no advocacy and no multipliers; it just makes sure the math is clean, reproducible, and ready for B003 to turn into recovery bands.

Post-cessation invoices (November 2019 – present) are tracked separately in the Invoice/Demand Log as conduct context; they are not principal paid. The log preserves dates, amounts demanded, transmission medium, and evidence references so the record can be used for pattern, notice, and deception narratives under the elected theory.

The Three-Period structure (P1 pre-Caldwell, P2 post-Caldwell, P3 Loft registered) is critical for legal significance but does not change the math — interest runs from each payment date regardless of which period the payment falls into.

END — Brown Tab B002 — Ledger & Interest Methodology — Three-Period Framework v1.5