The modern stack for a self-managed RV park portfolio

Six modules on one data layer. Every feature tagged with where it actually stands. Pick a section to drill in.

Prepared for Brent Smith / MHS Parks · From Ravi Parikh · July 2026 · Draft — for discussion, not a contract

Start here

Your stack today

6+systems
$50–100Kper year, software
$300/property/mo journaling
0systems that talk

Campspot

Reservations (3 parks)$10K/yr for a data dump

CampLife

Reservations900 reports, no builder

Rent Manager

Long-term + GL$1K/mo + $150/seat

IMS

Investor / waterfalls$12K/yr

AvidPay

AP fulfillmentKeeps working

Asset Tiger

Asset registry+ spreadsheets
Campspot nightly CSV export → Rent Manager

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

"Capital wants transparency… you can't give them this spaghetti bowl of crap."— you, about 40 minutes into our call

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.

The shape

One core. Five modules. Real APIs.

RESERVATION CORE

availability · bookings · payments · checkout — live today, untouched
READS ⇄

CRM

Consumes booking events. One fail-open lookup back (do-not-rent flags). Never blocks a booking.

WRITES →

Tenancy

A lease places a hold on its site. One calendar — double-booking a resident is impossible.

STREAM

Accounting

Booking money + lease money feed one stream. Books built natively — no QuickBooks, nothing to reconcile.

NONE

Investor reporting

Reads the accounting stream only. Fully insulated from bookings.

WAREHOUSE

Intelligence

Everything lands in one warehouse. Cross-system questions become one query.

Modules, not a forkliftAdopt one at a time over APIs.
Your data is yoursFull export, always. No $10K cron jobs.
One write, everywherePost once; every module sees it. The nightly CSV dies.
Reports are questionsAsk for the report you want. No 900-report library.

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

Module 1 · Live today

Reservations

Replaces: Campspot, CampLife

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

In production6
Booking engineOnline reservations, nightly through monthly, real-time availability.Live
Rate managementSeasonal rates, rules, fees, deposits by site type.Live
Front deskGrid view, check-in/out, walk-ins, moves, holds.Live
PaymentsCard + ACH, refunds, per-park merchant accounts.Live
Marketplace demandRoverPass marketplace feeds bookings into the same inventory.Live
Unified inventoryEvery site exists once, on one calendar — no split park map.Live

Module 2 · Spec now · build starts this quarter

CRM & guest communications

Replaces: the gap — nothing you run today does this. Reviewable build ~30 days after start; we're dogfooding it internally.

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

Contacts & profiles7
Unified contactOne record per human across your whole portfolio.Phase 1
Multi-contact per rigHusband + wife + kids, with roles. Collected post-arrival.Phase 1
Dedup & mergeAuto-match on phone/email; reviewable, reversible merges.Phase 1
TimelineEvery stay, payment, message, call, note — one history.Phase 1
FlagsVIP, do-not-rent, payment risk — shown loudly at booking time.Phase 1
Guest detailsRig type/length/amps, pets, household, preferences.Phase 1
Computed fieldsLifetime nights, spend, last stay, open balance.Phase 1
Leads & pipeline8
Lead types & stagesTransient, seasonal, long-term application, group — editable stages.Phase 2
Seasonal waitlistRanked per site type; notify next in line, one click.Phase 2
Phone intakeAI answers → lead auto-created. Missed call → transcribed voicemail lead.Phase 2
Email intakeForward your park inbox; AI parses it into a contact + lead + drafted reply.Phase 2
Web & walk-inForm embeds post straight in; walk-ins in seconds.Phase 2
Triage queueAnything unparseable lands in one daily queue. No lead dies in an inbox.Phase 2
Lead → leaseWon lead becomes a reservation or application. Zero re-entry.Phase 2
Tasks & today-list"Call back Tuesday" — a daily worklist for the desk.Phase 2
Communications6
Email + SMS composerSend as the park, threaded on the contact, any shift sees it all.Phase 1
Broadcast announcements"Laundry closed" to everyone currently on-park, instantly.Phase 2
Shared inboxReplies route back per park — one conversation.Phase 2
TemplatesMerge fields: name, dates, site, balance, payment link.Phase 1
DeliverabilityDomains, auth, reputation, opt-outs — handled by us.Phase 1
AI call loggingCall summaries land on the timeline automatically.Phase 2
Automations — toggles, not a builder7
Pre-arrivalN days before check-in.Phase 2
Post-stay review askThank-you + review request after checkout.Phase 2
Win-back"You stayed last summer — dates are open."Phase 2
Renewal reminderAgreement expiring in N days.Phase 2
Waitlist notifySpot opened → next in line pinged.Phase 2
Stale-lead nudgeAlerts your staff when a lead sits untouched.Phase 2
Contact-completionBugs occupants until you have everyone's info. Your idea.Phase 2
Segments & campaigns4
Segment builder"Winter Texans I want to hit in July" = a saved, auto-updating list.Phase 3
One-off campaignsTemplated email to a segment, with metrics.Phase 3
CSV exportAny segment, out, any time.Phase 3
Managed marketingOur team runs it for you if you'd rather not staff it.Phase 3

Module 3 · Live engine, upgrading

Long-term tenancy

Replaces: Rent Manager

Liverecurring monthly billing + proration
Liveautopay + payment links
Liveauto late fees
Liveper-site metering

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

1

The site

A lease holds its site on the one calendar. Double-booking a resident: impossible.

2

Invoicing

Today's recurring invoices upgrade to ledgers, per park, opt-in.

3

The person

Guest and resident = one CRM contact, one history.

4

The money

Stay money and lease money never mix — unified only in the books.

5

Shared rails

Same payments, same dashboard, leased lots visible on the grid.

Applications & screening7
Application formPer site type: household, income, references, rig photos (10-year rule in the flow).Phase 1
Application feeCard at submission, posts as revenue.Phase 1
Document uploadID, income proof, rig photos on the record.Phase 1
ScreeningBackground/credit/eviction via partner; role-restricted results.Phase 2
Review & decisionApprove/deny queue; FCRA adverse-action notice auto-generated.Phase 2
Approved → leaseEverything carries into the lease. Zero re-entry.Phase 1
Waitlist linkageFull site type? Application parks on the waitlist, pre-screened.Phase 2
Leases & billing — upgrading the live engine7
Recurring billingMonthly + fixed-interval invoices, prorated, auto-generated.Live
AutopayCard-on-file per schedule, guest payment links.Live
Rent-roll dashboardEvery long-term guest, balance, next bill, autopay status — one screen. (A first-cut rent-roll report is already built in the warehouse, unreleased.)Phase 1
Guided monthly setupOne flow replaces today's four separate screens.Phase 1
Lease docs + e-signSigned online, renewals programmed, increases with notices.Phase 1
Person-level balancesRunning balance + partial payments across invoices.Design w/ eng
Deposits as liabilitiesHeld properly; itemized disposition at move-out.Phase 2
Metered utilities — upgrading the live model5
Meters & readsElectric/gas/water per site, rollover handling, CSV import.Live
Auto-billing from readsRead → charge on the next invoice, automatically. Today it's manual per read.Phase 1
Mobile captureWalk-order entry on a phone, photo per read.Phase 2
Exception queueSpikes, negatives, missing reads held for review — nothing bills silently wrong.Phase 2
Rate structuresTiers, base fees, pass-through-at-cost. Today: flat rate only.Phase 2
Delinquency & deposits5
Late feesAuto-applied today; upgrading to your rules (any grace, recurring, caps).Live → up
Aging dashboard0–30/60/90+ across the portfolio.Phase 1
NoticesLate/demand/non-renewal, merge-filled from real balances, logged.Phase 2
Eviction-path controlsFlag a tenancy → partial payments blocked automatically.Phase 2
Cash at retailUnbanked residents pay cash at national counters; posts automatically.Phase 2

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

Module 4 · Own system, on purpose · 56 features specced across A1→A3

Accounting

Replaces: Rent Manager's GL, QuickBooks, and the nightly offshore journaling

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

Opposite invariantsOperations edit records; books never do. Append-only, debits = credits, periods lock.
Blast radiusOps ships daily; books change slowly and audited. Separate systems, separate risk.
Entity-firstThe first-class object is the legal entity (your SPEs) — mapped to parks, not owned by them.
One stream inBooking money + lease money + distributions arrive as charge-coded events. The GL is derived, never re-keyed.
Entities & chart of accounts5 ACC-01 · Entity registryYour LLCs/SPEs as first-class records.A1Read → ACC-02 · Entity ↔ park mappingEach park's money routes to exactly one owning entity.A1Read → ACC-03 · Chart of accounts templatesA park-industry CoA installed at entity creation.A1Read → ACC-04 · CoA managementAdd, rename, nest, merge, and archive accounts per entity.A1Read → ACC-05 · System accountsThe pinned accounts the platform posts to automatically.A1Read →
Journal engine6 ACC-06 · Journal entries & linesThe append-only, double-entry core of the whole system.A1Read → ACC-07 · Reversals & correctionsThe only way to change the past.A1Read → ACC-08 · Period lockingClosed months don't change.A1Read → ACC-09 · Cash + accrual viewsBoth accounting bases from one journal.A1Read → ACC-10 · Manual journal entriesHuman postings for the things automation can't know.A1Read → ACC-11 · Audit trailWho did what, when, to the books.A1Read →
Ingestion — books that write themselves6 ACC-12 · Event stream consumerThe one door money-facts enter through.A1Read → ACC-13 · Posting rulesCharge code + context → the right journal lines.A1Read → ACC-14 · Mapping controlsWhere your bookkeeper adjusts the rules.A1Read → ACC-15 · Exception queueNothing misbooks silently.A1Read → ACC-16 · Integrity checkPlatform facts vs. the books, checked daily.A1Read → ACC-17 · Sales-tax trackingCollected tax, visible and owed, by jurisdiction.A1Read →
Banking & reconciliation7 ACC-18 · Bank feedsEvery entity bank account, connected.A2Read → ACC-19 · Import & dedupClean, unique bank lines.A2Read → ACC-20 · AI categorizationA first-pass bookkeeper on every bank line.A2Read → ACC-21 · Stripe payout decompositionEvery payout split and matched — the reconciliation hours disappear.A2Read → ACC-22 · Cash-network settlementWalmart cash payments trace end-to-end.A2Read → ACC-23 · Bank reconciliationThe monthly proof, mostly automated.A2Read → ACC-24 · Transfer detectionMoney between your own accounts isn't income.A2Read →
Vendors & accounts payable10 ACC-25 · Vendor recordsOne vendor list, shared across your org.A2Read → ACC-26 · W-9 collectionGet the form before the money.A2Read → ACC-27 · COI trackingInsurance certificates with teeth.A2Read → ACC-28 · 1099 generation + e-fileJanuary without spreadsheets.A2Read → ACC-29 · Bill inboxVendors change nothing; bills just arrive.A2Read → ACC-30 · AI bill codingThe AI reads the bill.A2Read → ACC-31 · Approval workflowsWho says yes before money moves.A3Read → ACC-32 · Payment executionBills get paid — ACH, printed and mailed checks, or card.A3Read → ACC-33 · Recurring billsThe utility bill that comes every month.A2Read → ACC-34 · Vendor historyEverything about a vendor, one screen.A2Read →
Reporting & close11 ACC-35 · P&LThe statement small operators buy the module for.A1Read → ACC-36 · Balance sheetAt enterprise: the ownership stack, on the statement.A3Read → ACC-37 · Trial balanceThe accountant's home screen.A1Read → ACC-38 · GL detailEvery line, filterable, traceable to its source.A1Read → ACC-39 · AR/AP agingWho owes you, whom you owe, bucketed.A2Read → ACC-40 · Per-park P&LOne entity, two parks, three correct P&Ls.A1Read → ACC-41 · Comparative periodsThis July vs. last July, no exports.A1Read → ACC-42 · Consolidated rollupsThe portfolio view across all entities.A3Read → ACC-43 · Close checklistMonth-end, systematized — and a cockpit for closing many entities.A2Read → ACC-44 · Accountant accessA free, read-only seat for your CPA.A2Read → ACC-45 · Tax packageOne export that ends the January scramble.A2Read →
Equity & intercompany5 ACC-46 · Partner equity structureThe ownership stack, in the chart of accounts.A3Read → ACC-47 · Contribution & distribution postingCapital in and out, posted once, correct everywhere.A3Read → ACC-48 · Capital roll-forwardsThe per-partner artifact K-1 preparers need.A3Read → ACC-49 · IntercompanyFifteen LLCs that borrow from each other, kept honest.A3Read → ACC-50 · Management feesThe monthly mgmt-co ritual, automated.A3Read →
Onboarding & migration3 ACC-51 · Onboarding wizardEntity to books-flowing in one sitting.A1Read → ACC-52 · Opening balancesStart from truth, not zero.A1Read → ACC-53 · Cutover policyGo-forward only — stated, enforced, visible.A1Read →
Platform3 ACC-54 · Embedded UIYou never know it's a separate system.A1Read → ACC-55 · Roles & permissionsBooks-specific access control.A1Read → ACC-56 · BudgetsPlan vs. actual, at the account level.A3Read →

Not in this catalog, on purpose: payroll (integrate), depreciation automation (your CPA, v1), tax prep/filing, trust accounting, multi-currency, true consolidation eliminations. The gating input for the enterprise phase is the working session on your books.

Module 4 · Accounting · Entities & chart of accounts

ACC-01 · Entity registry

Your LLCs/SPEs as first-class records. A1

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

Builds on: Nothing — this is the first brick.

Done when: All 9+ of your LLCs entered with correct EINs; a dissolved entity keeps readable books but rejects new postings.

Module 4 · Accounting · Entities & chart of accounts

ACC-02 · Entity ↔ park mapping

Each park's money routes to exactly one owning entity. A1

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

Builds on: ACC-01.

Done when: Move a park between entities mid-year and both P&Ls split cleanly at the date, prior months untouched.

Module 4 · Accounting · Entities & chart of accounts

ACC-03 · Chart of accounts templates

A park-industry CoA installed at entity creation. A1

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

Builds on: ACC-01.

Done when: A campground CPA recognizes a new entity's chart without edits.

Module 4 · Accounting · Entities & chart of accounts

ACC-04 · CoA management

Add, rename, nest, merge, and archive accounts per entity. A1

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

Builds on: ACC-03.

Done when: Archiving an account with a balance is impossible except through the reclass flow.

Module 4 · Accounting · Entities & chart of accounts

ACC-05 · System accounts

The pinned accounts the platform posts to automatically. A1

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

What it must do

Builds on: ACC-03.

Done when: Deleting the deposit-liability account is impossible from any UI or API.

Module 4 · Accounting · Journal engine

ACC-06 · Journal entries & lines

The append-only, double-entry core of the whole system. A1

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

Builds on: ACC-01 through ACC-05.

Done when: A direct database UPDATE on a posted line fails at the constraint level, not just the app level.

Module 4 · Accounting · Journal engine

ACC-07 · Reversals & corrections

The only way to change the past. A1

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

Builds on: ACC-06, ACC-08.

Done when: Original, reversal, and correction all visible and linked in the GL, with the net effect correct in both periods.

Module 4 · Accounting · Journal engine

ACC-08 · Period locking

Closed months don't change. A1

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

Builds on: ACC-06.

Done when: A refund event dated into a locked month lands in the review queue, not the ledger.

Module 4 · Accounting · Journal engine

ACC-09 · Cash + accrual views

Both accounting bases from one journal. A1

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

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

Done when: An unpaid December invoice shows on the December accrual P&L and the January cash P&L (paid Jan 5) — same journal, no duplicates.

Module 4 · Accounting · Journal engine

ACC-10 · Manual journal entries

Human postings for the things automation can't know. A1

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

Builds on: ACC-06.

Done when: A CPA posts year-end depreciation with the schedule PDF attached, identifiable as manual in the GL.

Module 4 · Accounting · Journal engine

ACC-11 · Audit trail

Who did what, when, to the books. A1

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

What it must do

Builds on: All Area 1–2 features.

Done when: “Why does March look different than it did in April's board packet?” is answerable from the trail alone.

Module 4 · Accounting · Ingestion — books that write themselves

ACC-12 · Event stream consumer

The one door money-facts enter through. A1

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

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

Done when: Replaying a full day of events creates zero duplicate journal entries.

Module 4 · Accounting · Ingestion — books that write themselves

ACC-13 · Posting rules

Charge code + context → the right journal lines. A1

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

What it must do

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

Done when: A reservation payment posts to clearing, revenue, tax liability, and fee expense with zero human touch.

Module 4 · Accounting · Ingestion — books that write themselves

ACC-14 · Mapping controls

Where your bookkeeper adjusts the rules. A1

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

Builds on: ACC-13.

Done when: Remap “pet fee” to a new income account: old postings unchanged, new ones flow correctly.

Module 4 · Accounting · Ingestion — books that write themselves

ACC-15 · Exception queue

Nothing misbooks silently. A1

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

Builds on: ACC-12, ACC-13.

Done when: A brand-new charge code queues its events, gets mapped once, and every queued event posts — none lost, none guessed.

Module 4 · Accounting · Ingestion — books that write themselves

ACC-16 · Integrity check

Platform facts vs. the books, checked daily. A1

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

Builds on: ACC-12, ACC-13.

Done when: Delete one event in a test environment and the check turns red next morning, naming the exact gap.

Module 4 · Accounting · Ingestion — books that write themselves

ACC-17 · Sales-tax tracking

Collected tax, visible and owed, by jurisdiction. A1

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

What it must do

Builds on: ACC-13.

Done when: “What do we owe Texas for June?” is one report that ties to platform-collected tax to the penny.

Module 4 · Accounting · Banking & reconciliation

ACC-18 · Bank feeds

Every entity bank account, connected. A2

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

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

Done when: A broken connection alerts before month-end, not during close.

Module 4 · Accounting · Banking & reconciliation

ACC-19 · Import & dedup

Clean, unique bank lines. A2

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

What it must do

Builds on: ACC-18.

Done when: Importing an overlapping CSV after a feed backfill creates zero duplicates.

Module 4 · Accounting · Banking & reconciliation

ACC-20 · AI categorization

A first-pass bookkeeper on every bank line. A2

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

Builds on: ACC-19, ACC-13.

Done when: After one month of corrections, 80%+ of a typical entity's bank lines auto-post correctly.

Module 4 · Accounting · Banking & reconciliation

ACC-21 · Stripe payout decomposition

Every payout split and matched — the reconciliation hours disappear. A2

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

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

Done when: A month of payouts reconciles to bank deposits to the penny with zero manual matching.

Module 4 · Accounting · Banking & reconciliation

ACC-22 · Cash-network settlement

Walmart cash payments trace end-to-end. A2

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

What it must do

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

Done when: A $500 cash rent payment traces register receipt → resident ledger → settlement batch → bank deposit.

Module 4 · Accounting · Banking & reconciliation

ACC-23 · Bank reconciliation

The monthly proof, mostly automated. A2

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

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

Done when: A fully-fed account reconciles in under 5 minutes of human time.

Module 4 · Accounting · Banking & reconciliation

ACC-24 · Transfer detection

Money between your own accounts isn't income. A2

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

What it must do

Builds on: ACC-19, ACC-49.

Done when: A $10k move between two LLCs books as due-to/due-from on both sides from one confirmation.

Module 4 · Accounting · Vendors & accounts payable

ACC-25 · Vendor records

One vendor list, shared across your org. A2

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

Builds on: ACC-01.

Done when: “Joe's Septic” exists once for the org and codes correctly per entity by default.

Module 4 · Accounting · Vendors & accounts payable

ACC-26 · W-9 collection

Get the form before the money. A2

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

Builds on: ACC-25.

Done when: Paying a new 1099 vendor without a W-9 requires an explicit, logged override.

Module 4 · Accounting · Vendors & accounts payable

ACC-27 · COI tracking

Insurance certificates with teeth. A2

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

Builds on: ACC-25.

Done when: The AC contractor's lapsed COI is visible on the very bill approval where it matters.

Module 4 · Accounting · Vendors & accounts payable

ACC-28 · 1099 generation + e-file

January without spreadsheets. A2

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

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

Done when: The year-end 1099 run goes from review to filed without leaving the platform.

Module 4 · Accounting · Vendors & accounts payable

ACC-29 · Bill inbox

Vendors change nothing; bills just arrive. A2

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

What it must do

Builds on: ACC-01.

Done when: The same invoice emailed twice creates exactly one bill.

Module 4 · Accounting · Vendors & accounts payable

ACC-30 · AI bill coding

The AI reads the bill. A2

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

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

Done when: 90%+ of a pilot entity's bills need zero coding edits after 60 days.

Module 4 · Accounting · Vendors & accounts payable

ACC-31 · Approval workflows

Who says yes before money moves. A3

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

Builds on: ACC-30.

Done when: A $3,000 bill cannot reach payable without the owner's recorded approval when thresholds say so.

Module 4 · Accounting · Vendors & accounts payable

ACC-32 · Payment execution

Bills get paid — ACH, printed and mailed checks, or card. A3

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

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

Done when: One approved bill paid by ACH and one by mailed check, both auto-posted and traceable through bank rec.

Module 4 · Accounting · Vendors & accounts payable

ACC-33 · Recurring bills

The utility bill that comes every month. A2

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

What it must do

Builds on: ACC-29, ACC-30.

Done when: The electric bill arriving 40% high gets flagged, not auto-coded.

Module 4 · Accounting · Vendors & accounts payable

ACC-34 · Vendor history

Everything about a vendor, one screen. A2

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

Builds on: ACC-25 through ACC-32.

Done when: “How much have we paid Joe's Septic this year, and are we covered?” is one look.

Module 4 · Accounting · Reporting & close

ACC-35 · P&L

The statement small operators buy the module for. A1

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

Builds on: Areas 1–3.

Done when: A CPA accepts the year-end P&L for tax prep without adjustment questions beyond normal year-end items.

Module 4 · Accounting · Reporting & close

ACC-36 · Balance sheet

At enterprise: the ownership stack, on the statement. A3

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

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

Done when: Your controller puts our syndication balance sheet next to Rent Manager's and finds the same ownership stack.

Module 4 · Accounting · Reporting & close

ACC-37 · Trial balance

The accountant's home screen. A1

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

Builds on: ACC-06.

Done when: The TB always sums to zero and any line drills to detail.

Module 4 · Accounting · Reporting & close

ACC-38 · GL detail

Every line, filterable, traceable to its source. A1

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

Builds on: ACC-06, ACC-11.

Done when: From a P&L anomaly to the exact guest reservation behind it in four clicks or fewer.

Module 4 · Accounting · Reporting & close

ACC-39 · AR/AP aging

Who owes you, whom you owe, bucketed. A2

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

Builds on: ACC-12, ACC-29.

Done when: AP aging always equals the sum of unpaid approved bills.

Module 4 · Accounting · Reporting & close

ACC-40 · Per-park P&L

One entity, two parks, three correct P&Ls. A1

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

Builds on: ACC-06, ACC-13.

Done when: An entity owning two parks produces each park's P&L and the combined one, all correct.

Module 4 · Accounting · Reporting & close

ACC-41 · Comparative periods

This July vs. last July, no exports. A1

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

What it must do

Builds on: ACC-35, ACC-37.

Done when: A 12-month P&L renders in one view and exports cleanly.

Module 4 · Accounting · Reporting & close

ACC-42 · Consolidated rollups

The portfolio view across all entities. A3

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

What it must do

Builds on: ACC-36, ACC-49.

Done when: The 15-entity portfolio P&L never silently double-counts management fees.

Module 4 · Accounting · Reporting & close

ACC-43 · Close checklist

Month-end, systematized — and a cockpit for closing many entities. A2

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

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

Done when: Forty entities' close states on one screen; a red check blocks the lock.

Module 4 · Accounting · Reporting & close

ACC-44 · Accountant access

A free, read-only seat for your CPA. A2

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

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

Done when: Your CPA self-serves the entire year-end without emailing anyone for reports.

Module 4 · Accounting · Reporting & close

ACC-45 · Tax package

One export that ends the January scramble. A2

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

What it must do

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

Done when: A CPA confirms the package contains everything needed to prepare the return.

Module 4 · Accounting · Equity & intercompany

ACC-46 · Partner equity structure

The ownership stack, in the chart of accounts. A3

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

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

Done when: Each SPE's balance sheet shows each partner's capital position by class.

Module 4 · Accounting · Equity & intercompany

ACC-47 · Contribution & distribution posting

Capital in and out, posted once, correct everywhere. A3

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

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

Done when: A distribution posts once and appears identically in the LP's statement and the entity's balance sheet.

Module 4 · Accounting · Equity & intercompany

ACC-48 · Capital roll-forwards

The per-partner artifact K-1 preparers need. A3

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

Builds on: ACC-46, ACC-47.

Done when: The K-1 preparer uses our roll-forward without rebuilding it in Excel.

Module 4 · Accounting · Equity & intercompany

ACC-49 · Intercompany

Fifteen LLCs that borrow from each other, kept honest. A3

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

Builds on: ACC-05, ACC-24.

Done when: The org-wide intercompany report nets to zero, or shows exactly which pair is broken.

Module 4 · Accounting · Equity & intercompany

ACC-50 · Management fees

The monthly mgmt-co ritual, automated. A3

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

Builds on: ACC-49.

Done when: Month-end management fees across the whole portfolio post from one reviewed click.

Module 4 · Accounting · Onboarding & migration

ACC-51 · Onboarding wizard

Entity to books-flowing in one sitting. A1

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

Builds on: ACC-01 through ACC-14.

Done when: A design-partner owner reaches “events posting, P&L populating” in one sitting.

Module 4 · Accounting · Onboarding & migration

ACC-52 · Opening balances

Start from truth, not zero. A1

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

Builds on: ACC-51.

Done when: The day-one balance sheet matches the old system's closing trial balance exactly.

Module 4 · Accounting · Onboarding & migration

ACC-53 · Cutover policy

Go-forward only — stated, enforced, visible. A1

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

Builds on: ACC-12, ACC-52.

Done when: No duplicate revenue at the cutover boundary.

Module 4 · Accounting · Platform

ACC-54 · Embedded UI

You never know it's a separate system. A1

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

What it must do

Builds on: The dashboard token pattern.

Done when: Moving from reservations to the P&L requires no second login and no visible domain change.

Module 4 · Accounting · Platform

ACC-55 · Roles & permissions

Books-specific access control. A1

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

Builds on: ACC-54.

Done when: A park manager with operations access sees no financials without an explicit grant.

Module 4 · Accounting · Platform

ACC-56 · Budgets

Plan vs. actual, at the account level. A3

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

Builds on: ACC-35.

Done when: The July P&L shows budget, actual, and variance per line for a budgeted entity.

Module 5 · In scoping · sequenced last

Investor & fund reporting

Replaces: IMS — eventually. Keep IMS until this earns it.

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

Why nobody else can build this right

IMS · ~$12K/yr

What you run. No connection to the operating system — everything re-keyed.

Juniper Square · $25–40K/yr

Institutional. Yardi/QB connectors, still not PMS-native.

Agora · $9–15K/yr

Mid-market. QuickBooks only.

InvestNext · $6–9K/yr

Visual waterfall builder. QuickBooks only.

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.

Deals & capital accounts3
Deal registryOne syndication per property: deal ↔ SPE ↔ park, ownership mirrored from the books.Scoping
LP positions"Here are my six deals, positions, and metrics" — one login.Scoping
Capital accountsAppend-only per LP per deal: contributions, distributions, pref accrual.Scoping
Waterfalls & distributions3
Waterfall engineComposable tranche stack: pref (cumulative/compounding), return of capital, catch-up, share classes, multi-tier promotes, side letters — separate op-cash and capital-event waterfalls. Every run shows per-LP tier math.Scoping
Distribution runsAvailable cash → tier math shown line-by-line → approve → paid → posted back to the books.Scoping
K-1 packageTrial balance + capital account roll-forwards to your CPA. We package; your preparer prepares.Scoping
LP portal3
Investor loginPositions, distribution history, capital account statements, documents.Scoping
Performance metricsCash-on-cash and equity multiple first; IRR later (defensible numbers before debatable ones).Scoping
Deal announcementsUpdates to all LPs in a deal, logged.Scoping
Capital calls — fast follow2
Call runsPro-rata amounts, LP notices, collection tracking — the mirror of a distribution. Built for the profile that doesn't stack cash against the refi wall.Scoping
Committed / called / receivedCapital accounts model all three from day one, so calls bolt on without rework.Scoping

Deliberately out: fundraising tooling (data rooms, subscription docs), fund-of-funds, ACH debits from LPs in v1 (wire/check tracking first). Your partner raises; the pain is reporting. And this module only starts after the per-entity GL is proven — before that, it would just be IMS again.

Module 6 · Reports live · cross-system layer phased

Intelligence & reporting

Replaces: analytics upsells, the 900-report library, the Excel glue

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

The reporting layer7
Report library~48 warehouse-backed reports live today: occupancy & revenue (w/ drill-downs), pace YoY, arrivals/departures/in-house, payouts, tax, POS, meter reads. CSV/XLSX export.Live
Chat report builder"Six columns, July vs last July, same-store." Describe it, get it.Phased
Budget vs. actualForward bookings against plan, not just history.Phased
Mix analysis"Lost monthlies, better on transients?" — finally answerable.Phased
Same-store compsIdentical inventory, year over year, across the portfolio.Phased
Scheduled reportsAny saved report, emailed on your cadence.Phased
Export / APIEverything, always, no ransom.Phased

The plan

Sequencing & the ask

now

Specs + accounting scoping

These docs, plus a working session on your entity/GL structure — the biggest open decision.

Q3

CRM build starts

Reviewable build ~30 days after start. We dogfood it as our own CRM.

Tenancy upgrades

Rent-roll dashboard, guided monthly setup, auto utility billing, flexible late fees, deposits.

Accounting layer

Native P&L → per-entity GL, shaped by the scoping session. The Rent Manager conversation gets real.

later

Investor reporting

Scoped only after the ledger is proven in production.

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

< todaytarget vs. your aggregate spend
per lotnot per seat — whole team logs in
freedata export, forever

What I want from you

1

Pick this apart

What's missing, mislabeled, or in the wrong phase.

2

One accounting session

Your entity structure and close process — the reference case for the GL.

3

30-day CRM look

Tell me where the first build is wrong.

Said plainly: no contract, no commitment, no switching pressure. Your brain on the design; founding terms if it earns your business. If something here is wrong, I'd rather hear it this month than after we've built it.

RoverPass · Working framework · July 2026 · ravi@roverpass.com