One reporting layer

The owner report your PMS cannot produce, built for your stack.

For property managers running more than one system, one normalized view of per-property performance against what you underwrote.

Automatic owner and investor statements. The monthly close, current instead of reconstructed.

The situation

Past two or three acquisitions, your portfolio runs on a mix of systems that were never meant to sit together. Each PMS reports its own properties in its own format, and none of them was built to answer the question you actually need answered: how much is this single property making me, the management company, after payroll, marketing, software, and overhead, not just in gross booking revenue.

So the real reporting lives outside all of them. Exports from each system land in a spreadsheet, formulas allocate revenue and fees across owners and entities, and a few days later you have numbers for a month that has already closed. The owners who trust you with their assets, and the investors underwriting the next acquisition, are asking for clarity at precisely the moment your answer depends on a spreadsheet only one person fully understands.

Two or three acquisitions in, or one PMS switch, is usually where this starts. The unit count matters less than the number of systems: the data is in too many places, and reporting has become a record of what happened rather than a way to steer.

What we build

A reporting layer that sits above every system you run and normalizes them into one model.

01

Per-property profit and loss against underwriting. Real costs in, owner by owner, entity by entity, not gross revenue dressed up as profit.

02

Automatic owner and investor statements. Generated in the format each owner is owed, including the year-end statement that has to match the 1099, so January stops being a manual rebuild.

03

Portfolio-level performance across whatever mix of PMSs the portfolio runs on, including the systems an acquisition leaves you holding.

04

A current close. The view updates from your systems instead of being reconstructed by hand each month.

05

What is coming, not only what happened. Projected owner payouts, what is reserved against them, and your own working capital, from the bookings already on the calendar, before the month closes. Every tool in this category reports backwards. The forward view is the one nobody keeps current for you, and the data to build it is already in your bookings.

It runs on top of your existing PMSs. No forced migration, no new tool for your owners to learn.

Works with the stack you already run

We normalize reporting across the systems mixed portfolios actually run on: Guesty, Hostaway, Hostfully, OwnerRez, Track, Streamline, Escapia, Hospitable, Lodgify, and Smoobu on the short-term side, Mews and Apaleo on the serviced-apartment and aparthotel side, and Buildium, AppFolio, or Rent Manager where a portfolio mixes short and long-term lets. We sync to the accounting system you actually use, QuickBooks, Xero, Sage, or a local ledger mapped per engagement, rather than only the one target a US product happens to support. If a system has an API or even a reliable export, we can build against it, including the PMS an acquisition left you holding. That portfolio is where the studio's name comes from: the operators we build for are the ones running many stacks at once.

Why not a BI tool or a bookkeeping product

A generic BI tool draws charts but does not understand owner-fund structure or lodging economics, so the work of teaching it what an owner statement is lands back on you. Productized accounting tools are a different matter, and more capable than they look: the good ones carry a real rule engine and will handle most owner-statement math on a PMS they support. When that is genuinely your situation, they are the cheaper answer and we will say so on the first call. Where they stop is the mixed stack itself, a stack they do not support, a ledger they do not sync to, and the case where you want to own the logic rather than rent it. That is the build.

We can do it because we built the regulated financial core of a property-management platform that has run for fourteen years. Reporting that has to reconcile is the same discipline as trust accounting, which is the hardest version of it.

How the build goes

01

Show us your stack and a few real owner statements.

Free fit call. If a custom build is not the right answer for your situation, we will tell you on the first call.

02

A $2K discovery, one week.

We connect to your real systems, map how the data actually behaves, and hand you a firm fixed quote. Credited in full toward the sprint if you proceed.

03

A working prototype in two weeks.

We normalize two of your systems into one model and produce a real per-property report from your real data. You check it against what you know to be true.

04

The decision point.

If the numbers match what you know to be true and you trust it, we add the remaining systems and the owner and investor views. Fixed scope, fixed price, your code.

Proof

Trust accounting for Vacation Rental Connect, fourteen years in production and live today, including a live Guesty integration and booking-level payout reconciliation that recomputes each booking, surfaces the mismatches, and repairs them. Multi-tenant, multi-system production work across three continents.

Owner Money, Right to the Cent

Questions operators ask about reporting

Any mix with an API or a reliable export. In practice that means Guesty, Hostaway, Hostfully, OwnerRez, Track, Streamline, Escapia, Hospitable, Lodgify, and Smoobu, with Mews and Apaleo on the serviced-apartment side and Buildium, AppFolio, and Rent Manager on the long-term side. The point of the build is that the mix stops mattering to the owner reading the statement.

Show us your stack and one month you would normally rebuild by hand. We will show you that same month produced automatically, in two weeks, on your real numbers.

Free call focused on your operation or your platform, not a generic pitch. If a custom build is not the right answer for your situation, we will say so.