The modern stack for a self-managed RV park portfolio

Every night. By hand. Because the reservation system has no accounting.

The thesis: put operations, accounting, and investor reporting in one system and the RV park asset class becomes legible to institutional capital. Everyone still running the old stack is suddenly behind.

Blast radius of anything new = one module, never the platform. Modules with no core dependency build in parallel.

Core roleThis IS the core. Everything else attaches beside it, never inside it.

Core interactionReads events; one fail-open lookup back. Checkout untouched — still one email.

Verified by a full code audit: RoverPass already runs this engine in production at real volume. This module upgrades a live system — it is not a cold start.

The five tie-ins to the reservation core

Accounting is its own module → see Module 4 · Accounting. Lease money flows there on the accounting stream automatically.

Core interactionConsumes the accounting stream only. Deliberately its own system: append-only books that no booking-flow deploy can ever touch.

Everything in the accounting system hangs off a legal entity — not a park. This is the registry: each LLC or SPE you operate, with the facts the books need.

What it must do

• Name, EIN, entity type (LLC/LP/S-corp/sole prop), tax classification, fiscal-year start, default accounting basis (cash or accrual), address
• Status lifecycle: active → dissolved; a dissolved entity keeps its books readable forever but blocks new postings
• Entities can never be hard-deleted once they have journal history
• One owner organization holds many entities

Builds on: Nothing — this is the first brick.

Parks are operating assets; entities own them. This mapping is how a reservation at a park becomes revenue on the right LLC's books — and it's effective-dated, because parks get sold between entities mid-year.

What it must do

• One park maps to exactly one entity at a time; one entity can own many parks
• Mapping changes are effective-dated: sell a park to a new LLC July 1 and June revenue stays on the old entity, July posts to the new — no re-posting
• A park with no mapping is an ingestion exception, never a silent default

Builds on: ACC-01.

New entities shouldn't start from a blank chart. The template comes from our accounting team's campground practice — the accounts a park CPA actually expects.

What it must do

• Versioned template; account types (asset/liability/equity/income/expense) with normal-balance side
• Template updates never mutate existing entities' charts
• Installed automatically during onboarding

Builds on: ACC-01.

Owners and bookkeepers shape the chart over time — safely. The rules exist so nobody can strand a balance or corrupt history.

What it must do

• Account numbers unique per entity; renames are display-only (the underlying id never changes)
• Archive is blocked while an account holds a balance — an audited reclass flow moves the balance first
• Sub-account nesting to 3 levels; merge = reclass journal + archive in one audited step

Builds on: ACC-03.

Automated posting needs guaranteed destinations. These accounts are created with every entity and protected from deletion or re-typing.

What it must do

• Per entity: accounts receivable, clearing/undeposited funds per payment method, security-deposit liability, sales-tax liability, processing-fee expense, platform-fee expense, retained earnings, opening-balance equity
• Partner-equity classes added at the enterprise phase
• Visible in the chart with a system badge; cannot be archived or re-typed

Builds on: ACC-03.

Every dollar-fact becomes a balanced journal entry. The discipline is enforced by the database itself, not by app code that a bug could bypass.

What it must do

• Entry = header (entity, dates, source, memo) + lines (account, debit/credit, park dimension)
• Database-enforced: lines sum to zero; no UPDATE or DELETE on posted entries — ever
• Every automated line carries the id of the platform event that caused it
• Amounts stored in integer cents; posting date and effective date both kept, in the entity's timezone

Builds on: ACC-01 through ACC-05.

Books never get edited — mistakes get reversed and re-posted, leaving the full story visible. This is what makes the history defensible to a lender, buyer, or auditor.

What it must do

• A reversal is a new mirrored entry, linked both ways to the original, with a required reason
• A correction = reversal + new entry, performed as one audited operation
• Reversing something in a locked month posts into the earliest open period, flagged

Builds on: ACC-06, ACC-08.

Once a month is closed, it stays closed — the number you showed your lender in March is the number in the system in November.

What it must do

• Lock per entity per month; posting into a locked period is rejected
• Automated events dated into a locked period go to the exception queue for a human decision
• Unlock requires an elevated role and a reason, is logged, and auto-relocks
• Year-lock after tax filing

Builds on: ACC-06.

Operators want accrual to run the business and cash for taxes. Rent Manager does both; so do we — from the same entries, so the two can never disagree about the underlying facts.

What it must do

• Accrual view keys off effective dates; cash view keys off when payment was actually applied
• An invoiced-but-unpaid charge appears in accrual and not in cash — automatically
• Basis toggle on every report; per-entity default

Builds on: ACC-06, ACC-12 (charge events must link to their payments).

Depreciation from your CPA, an insurance accrual, an odd adjustment — there's a controlled door for humans, clearly marked as such everywhere.

What it must do

• Role-gated (bookkeeper/accountant; owner access is a per-org setting)
• Templates for recurring entries; attachments for the backing document
• Balanced-entry validation before submit; flagged as manual in every report

Builds on: ACC-06.

Every posting, lock, unlock, mapping change, and exception decision — logged immutably, readable by humans, kept for seven years.

What it must do

• Covers postings, reversals, locks/unlocks, chart changes, mapping changes, exception resolutions
• Human-readable before/after diff per event; exportable

Builds on: All Area 1–2 features.

Reservations, invoices, payments, refunds, payouts, store sales — the operating platform emits them as events, and this consumer turns them into journal entries. Idempotent and replay-safe, because books built on events are only as good as event handling.

What it must do

• Consumes all reservation-system and tenancy money events; fund distributions later
• Idempotent by event id: processing the same event twice produces nothing new
• Replay-safe: reprocessing a whole day nets zero new entries
• Lag monitoring with alerts

Builds on: The reservation system's event feed (a prerequisite build); ACC-06.

The brain of automated bookkeeping: every kind of platform charge knows which accounts it hits, with your entity routing applied.

What it must do

• Complete default rule set ships — every platform charge code mapped out of the box
• Rules key on charge code, payment method, and event type; routing via the park↔entity map
• Rule changes are effective-dated — history is never rewritten
• Simulation mode: preview what any event would post before going live

Builds on: ACC-02, ACC-05, ACC-12.

Defaults fit most parks; this is the screen for the rest — with guardrails so a mapping change can't quietly corrupt reports.

What it must do

• Per-entity overrides of any default mapping
• Validation warns on type mismatches (a revenue code aimed at an asset account)
• Change preview shows what future postings will be affected; every change audited and effective-dated

Builds on: ACC-13.

When automation isn't sure — unmapped code, unmapped park, event dated into a locked month — the item waits for a human instead of guessing. Same philosophy as the metering exception queue.

What it must do

• Exception types: unmapped charge code, unmapped park, locked-period event, malformed event, sign anomalies
• Queue per entity with age and severity; resolution = map-and-post, post-with-override, or dismiss-with-reason (all audited)
• Exceptions older than 7 days escalate to the bookkeeping dashboard

Builds on: ACC-12, ACC-13.

The books are derived from the operating platform — so every night we prove the derivation: do payments, refunds, and payouts on the platform equal what the ledger says?

What it must do

• Daily per-entity comparison with drill-to-source on any variance
• Event-gap detection (missing sequence numbers)
• Green/red status on the entity dashboard; red blocks the month from closing

Builds on: ACC-12, ACC-13.

Tax collected on the platform accrues to liability accounts automatically; the monthly report says what you owe whom.

What it must do

• Tax lines post to liability sub-accounts keyed by jurisdiction/tax config
• Monthly liability report per entity per jurisdiction; remittance recorded as a payment or entry
• Filing automation is explicitly out for v1 — the report feeds your existing filing process

Builds on: ACC-13.

Each LLC's accounts feed transactions daily. Connection health is monitored so a dead feed surfaces before month-end, not during close.

What it must do

• Bank aggregation with N accounts per entity, each tied to a ledger cash account
• Connection health monitoring and re-auth flows; CSV/OFX import fallback for feed-hostile banks
• We never store bank credentials

Builds on: ACC-01, ACC-05; aggregation provider selection.

Bank data arrives messy — feeds backfill, CSVs overlap, pending becomes posted. This layer guarantees each real transaction exists exactly once.

What it must do

• Dedup on provider transaction id plus fuzzy matching for CSV overlap
• Pending transactions visible but never booked; only posted lines post
• A bank line can never hit the ledger twice

Builds on: ACC-18.

The AI proposes the account and park for each transaction, auto-posts when confident, queues when not — and learns your corrections permanently.

What it must do

• Confidence-scored suggestions; auto-post above a per-entity threshold, review queue below
• Corrections become remembered rules (this payee → that account)
• Bulk review UI ordered by confidence

Builds on: ACC-19, ACC-13.

The single highest-value automation in the module. Each processor payout is decomposed into what it really is — gross collections, refunds, fees — posted correctly, and matched to the bank deposit it became.

What it must do

• Consume payout and balance-transaction data from the payments processor
• Decompose: gross collected − refunds − processing fees − platform fees = net payout
• Auto-match net to the bank deposit line; unmatched payouts age into the exception queue

Builds on: ACC-12, ACC-18, ACC-19.

When residents pay cash at retail, the provider settles in batches. Those settlements decompose and match exactly like card payouts.

What it must do

• Provider settlement file ingestion; per-resident detail ties to the resident's ledger
• Settlement batch matches its bank deposit

Builds on: ACC-21 pattern; the tenancy module's cash-at-retail feature.

Reconciliation is where books earn trust. The AI does the first pass; a human confirms the breaks; the result feeds the close checklist.

What it must do

• Per account per month: opening balance → matched lines → unmatched list → adjusted vs. statement balance
• AI first pass; human confirms exceptions only
• Reconciliation status feeds the close checklist

Builds on: ACC-19, ACC-20, ACC-21.

Transfers between accounts — and loans between your entities — are detected and booked as what they are.

What it must do

• Detect matching debit/credit pairs across accounts (same org, near dates and amounts)
• Same-entity pairs book as transfers; cross-entity pairs propose intercompany due-to/due-from
• Cross-entity never auto-books without confirmation

Builds on: ACC-19, ACC-49.

Vendors exist once at the org level with per-entity defaults, so Joe's Septic codes correctly whichever LLC he's working for.

What it must do

• Name, contacts, default expense account and park, payment terms, 1099-eligibility flag
• Org-level vendor, per-entity usage and defaults; duplicate-merge tool (audited)

Builds on: ACC-01.

Vendors self-serve their W-9 through a request link; the system warns (or blocks, your choice) when you try to pay a 1099-eligible vendor without one.

What it must do

• Request link with self-serve upload and TIN entry; stored on the vendor
• Payment warning, configurable to hard-block, for 1099-eligible vendors with no W-9
• TINs masked except for authorized roles

Builds on: ACC-25.

Certificates of insurance live on the vendor with expiry alerts — and the lapsed-coverage flag shows up at the exact moment it matters: bill approval.

What it must do

• Coverage type and expiry per certificate; alerts at 30/7/0 days
• Expired-COI flag surfaces on bill approval; report of active vendors with missing/expired coverage

Builds on: ACC-25.

Per-vendor totals compute all year from paid bills and categorized bank lines; at year-end you review and e-file through a partner without leaving the platform.

What it must do

• Card-paid amounts excluded per IRS rules; threshold logic built in
• Review screen → partner e-file → recipient copies delivered
• Corrections and amendments supported

Builds on: ACC-25, ACC-26, ACC-20; e-file partner.

Every entity gets a bills@ address. Vendors email invoices as they always have; the inbox catches, stores, and dedupes them.

What it must do

• Email-in with PDF/photo attachments; forwarded-email handling
• Dedup on file hash and extracted invoice number
• Paper/PO-box intake stays with the AP fulfillment partner for enterprise operators

Builds on: ACC-01.

Vendor, invoice number, dates, amount, line detail — extracted and coded with a confidence score. Below threshold it drafts for review; corrections teach it.

What it must do

• Vendor matching against the org list (or new-vendor creation flow)
• Proposed account and park coding with confidence; draft-and-review below threshold
• Corrections feed the same rules memory as bank categorization

Builds on: ACC-29, ACC-25, ACC-13.

Simple first — one approver per entity — then threshold chains for enterprise: managers approve small, owners approve big, with delegation for vacations.

What it must do

• Phase A2: single approver per entity
• Phase A3: threshold chains (e.g. manager under $500, owner above), per-entity config, delegation
• Approval state lives on the bill; every approval audited

Builds on: ACC-30.

We orchestrate; a payments partner moves the money and prints the checks. Includes the trick old-school vendors love: you pay by card, they receive a paper check.

What it must do

• Phase A2: record payments made outside the system (mark-paid)
• Phase A3: partner rails — ACH, printed + mailed checks, pay-by-card→vendor-gets-check
• Per-entity funding accounts; payment-status webhooks post automatically; voids and reissues handled

Builds on: ACC-31; rails partner selection (AvidXchange-class or Melio-class; Stripe Treasury ruled out — no checks).

Expected bills auto-match to their recurrence; a missing bill or a weird amount gets flagged instead of auto-coded.

What it must do

• Recurring schedule per vendor — fixed amount or variable with tolerance
• Missing-bill alerts; out-of-tolerance amounts route to review

Builds on: ACC-29, ACC-30.

Bills, payments, credits, running 1099 totals, W-9 and COI documents — the whole relationship in one place, exportable as a statement.

What it must do

• Per-vendor ledger with year-to-date totals
• Document panel (W-9, COIs); vendor statement export

Builds on: ACC-25 through ACC-32.

Per entity, either basis, by park or combined, with comparisons — and every line drills down to the exact transactions behind it.

What it must do

• Basis toggle (cash/accrual); park dimension: whole entity, one park, or side-by-side
• Comparative: vs. prior period and prior year
• Drill from any line → ledger detail → source platform record; CSV/XLSX/PDF export

Builds on: Areas 1–3.

A standard balance sheet from day one; at the enterprise phase it shows what Rent Manager shows you today — sub-entity investments and each partner's equity by class.

What it must do

• Phase A1: standard assets/liabilities/equity with drill-through
• Phase A3: sub-entity investment accounts; partner equity per class per partner (contributions, distributions, allocated earnings)

Builds on: ACC-06; enterprise phase: ACC-46 through ACC-48.

Opening, activity, closing for every account. Always sums to zero. Ties to the P&L and balance sheet by construction, because they're all the same journal.

What it must do

• Per entity per period; basis toggle; export
• Drill any account to detail

Builds on: ACC-06.

The forensic view: filter by account, period, park, source type, manual vs. automated — and jump from any automated line to the actual reservation, bill, or payout that caused it.

What it must do

• Filters: account / period / park / source type / manual vs. auto
• Source links on every automated line; export

Builds on: ACC-06, ACC-11.

Receivables from the operating platform and payables from unpaid bills, in standard 0-30/31-60/61-90/90+ buckets with drill-through. (Doesn't exist anywhere in the current product.)

What it must do

• AR aging from platform balances by entity and park
• AP aging from unpaid approved bills
• Drill to the underlying reservation, resident, or bill

Builds on: ACC-12, ACC-29.

Every platform-sourced line is stamped with its park. Entity-level costs (insurance, the owner's truck) get allocated across parks by rule — and allocated lines stay distinguishable from direct ones.

What it must do

• Park dimension on every platform line
• Allocation rules for shared costs: fixed % or per-site count
• Allocated vs. direct visually distinct on reports

Builds on: ACC-06, ACC-13.

Any statement, any number of periods side by side, with dollar and percent variance columns.

What it must do

• N periods side-by-side on any statement
• $ and % variance columns; export keeps the layout

Builds on: ACC-35, ACC-37.

Aggregated statements across any group of entities you define — with intercompany balances flagged so management fees never silently double-count.

What it must do

• Consolidation groups: org-defined subsets of entities
• Aggregated P&L and balance sheet; intercompany balances flagged
• True accounting eliminations deliberately deferred beyond A3

Builds on: ACC-36, ACC-49.

The ritual becomes a checklist: bank recs done, exceptions cleared, integrity green — then lock. The bookkeeping team sees every entity's close state on one screen.

What it must do

• Per entity per month: recs (ACC-23) + exceptions (ACC-15) + integrity (ACC-16) + drafts resolved → lock (ACC-08)
• Portfolio view: close status across all entities a bookkeeping team manages
• A red integrity check blocks the lock

Builds on: ACC-08, ACC-15, ACC-16, ACC-23.

Your accountant gets their own login per entity: every statement, the GL, the documents — export anything, change nothing. Accountants are a channel, not a cost.

What it must do

• Per-entity invite; read-only across statements, GL, TB, docs
• Full export; access audited and revocable; free seat

Builds on: ACC-35 through ACC-38, ACC-55.

Everything the preparer needs, bundled: trial balance, GL detail, both-basis statements, 1099 summary, capital roll-forwards where they exist.

What it must do

• One ZIP/PDF bundle per entity per year
• Bulk generation across all entities a bookkeeping team manages

Builds on: ACC-35 through ACC-38, ACC-28, ACC-48.

Equity classes per entity — Class A, Class B, GP — with per-partner sub-accounts for contributions, distributions, and allocated earnings. Partners are the same contact records the rest of the platform uses.

What it must do

• Equity classes per entity; per-partner sub-accounts
• Partners are CRM contacts with an investor role — shared identity with the investor-reporting module

Builds on: ACC-05; the CRM contact model.

Contributions and distributions hit the right partner sub-accounts automatically — and the investor module's capital accounts are views of these same numbers, so the LP statement and the balance sheet can never disagree.

What it must do

• Contributions post from bank matching or the fund module
• Distribution runs post automatically when approved
• Manual path with partner selection for use before the fund module exists

Builds on: ACC-46; investor-reporting distribution runs (later).

Opening capital + contributions + allocated earnings − distributions = closing. Per partner, per entity, per year — the thing that otherwise gets rebuilt in Excel every spring.

What it must do

• Allocated earnings default to ownership % with CPA override (tax allocations stay CPA territory)
• Bulk export into the tax package

Builds on: ACC-46, ACC-47.

Due-to/due-from account pairs that mirror automatically, plus the report that matters: across the whole org, intercompany must net to zero — or the report names the broken pair.

What it must do

• Paired accounts: Entity A “due from B” ⇄ Entity B “due to A”; posting one side prompts the mirror
• Org-wide nets-to-zero report with drill-through
• Feeds the bank transfer detection feature

Builds on: ACC-05, ACC-24.

Fee rules per entity pair — percent of revenue or flat — post income on the management company and expense on the property LLC from one reviewed click.

What it must do

• Fee rules per entity pair; monthly run with preview before posting
• Posts both sides plus the intercompany or cash settlement

Builds on: ACC-49.

A guided path: create the entity, map its parks, confirm the chart, review mappings, set the go-live date — resumable, and drivable by our bookkeeping team on your behalf.

What it must do

• Steps: entity → parks → CoA → mappings → go-live → (A2: bank connections)
• Progress saves; service-assisted mode where the bookkeeping team drives and the owner approves

Builds on: ACC-01 through ACC-14.

Import the closing trial balance from QuickBooks or Rent Manager as one opening entry at the cutover date. Must balance, or it doesn't post.

What it must do

• CSV import with QuickBooks and Rent Manager export templates
• Posts as a single opening entry against opening-balance equity
• Offered as a done-for-you service

Builds on: ACC-51.

Platform events from before your go-live date are excluded from posting (visibly, not silently). No full-history re-posting; historical documents attach for reference.

What it must do

• Ingestion excludes pre-cutover events with a visible count
• No duplicate revenue between imported balances and streamed events at the boundary

Builds on: ACC-12, ACC-52.

Accounting screens live inside the same owner dashboard as reservations — one login, an entity switcher, statements readable on your phone.

What it must do

• Embedded via the same session-token pattern as the CRM
• Entity switcher; statements mobile-readable, heavy workflows desktop-first

Builds on: The dashboard token pattern.

Financial data has its own roles — owner, entity admin, bookkeeper, approver, read-only accountant, auditor — granted per entity and enforced on the server.

What it must do

• Per-entity grants; server-side checks on every call
• Sensitive fields (TINs, bank numbers) masked by role

Builds on: ACC-54.

Annual budgets per account with monthly spreads; the P&L grows budget, actual, and variance columns; the cross-park intelligence views build on top.

What it must do

• Monthly spread: even or custom; seed from last year's actuals
• Budget-vs-actual columns on the P&L

Builds on: ACC-35.

Core interactionNone. Reads the accounting stream only — a view over the books, not a re-keying exercise.

Why nobody else can build this right

Every one of them re-keys or imports operating results. Here, distributions and LP metrics are computed from the same books that ran the properties — a view, not a workflow. That's structural, not a feature they can add.

Core interactionReads the shared warehouse everything streams into. No exports, no load on production.

Full stack, thoroughly QA'd: a six-to-twelve-month arc. Modules land along the way and are useful standalone.

What I want from you