Batch distributions are a workaround, not a workflow

Here is the claim, stated plainly so you can argue with it. The month-end distribution run is not a workflow. It is a workaround for software that loses track of money between the 1st and the 31st. The industry treats distribution day as a fixture of the job, something you schedule staff around and build the calendar on. It is neither. It is a symptom, and it points at one specific defect in how most property software records a rent payment.

The ritual, as it actually runs

It starts with an export. The rent roll comes out of the software and into a spreadsheet, because the software knows what was collected but not what any of it means. Then the rebuild begins. Management fees get recalculated by hand, because this owner negotiated 7 percent, that lease is on a flat fee, and the software only stores one rate. Ownership splits get resolved from a tab somebody maintains from memory. Repair invoices get netted against the right property, mostly. Reserves get topped up if anyone remembers. Nothing moves until the whole sheet balances.

Then one giant batch of owner payments goes out. And everyone holds their breath for the NSF that lands on the 28th and un-balances a month that was already closed. The clawback email to an owner who has already spent the money is the worst recurring conversation in this business.

Owners experience all of this as lag. Rent their tenant paid on the 3rd shows up in their account weeks later, and the statement explaining it arrives later still. The manager experiences it as risk concentrated into a single afternoon. One formula error, one stale ownership percentage, one bounced payment, and the batch is wrong in twenty places at once. Both readings are correct.

The month-end distribution run is not a workflow. It is a workaround for software that loses track of money between the 1st and the 31st.

Why the batch exists at all

The batch is not a preference anyone chose. It is a consequence of how the industry default records money. Most property software books a rent payment as an undifferentiated lump: cash in, tenant ledger credited, done. Whose money it is, what fee applies, which reserve it should feed, which two owners split the remainder 60/40: none of that is resolved at the moment of payment. The information exists. It is sitting in the lease, the management agreement, and the ownership table. The software just never brings it to the transaction.

So the money sits in the operating account, identity-less, until a human reconstructs its meaning at month-end. That reconstruction is the distribution run. Export, rebuild, resolve, hold, batch, pray. Every step on that list exists because the question "whose money is this" was deferred for thirty days. The spreadsheet is not the tool for the job. The spreadsheet is the accounting system, and the software is a collections front end taped to it.

Every rent payment already knows whose money it is. Batch runs exist because most property software never asks.

A test you can run on your own books

There is a simple diagnostic. Pick one rent payment from the 5th of last month and ask your system, today, what happened to it: how much became fee, how much went to reserves, how much reached which owner, and when. If the answer requires opening a spreadsheet, the system did not record those facts. Someone derived them, later, in bulk. That is the difference between a record and a reconstruction, and it is why the run has to exist.

If paying owners requires a distribution day, your ledger is a monthly reconstruction, not a record.

Distribution as an event, not a run

AXYS is built on the opposite premise: answer the question at the moment the payment arrives. Every rent payment runs through a per-payment distribution engine the instant it lands, and the payment splits into its components right there, as one recorded event.

• The management fee resolves through a cascade with strict precedence: the lease first, then a property-level rule, then a per-owner override, then the company default. The rate you negotiated with one owner is not a spreadsheet footnote. It is the rate the engine applies, automatically, to that owner’s payments and no one else’s.
• Withholding policies carve their amounts from the split at the same moment, so tax withholding and expense holdbacks come out of the gross rather than getting bolted on after.
• Reserve funding posts to per-property reserve sub-ledgers with numbered movements, so each property’s cushion fills as its own rent arrives and every movement is individually traceable.
• What remains is the owner distribution: the owner net, split by ownership share when a property has multiple owners, routed to each owner’s payout destination.

Then it settles, per event. The split for the payment that arrived on the 3rd settles on its own; it does not wait for the payment arriving on the 9th. There is no distribution run at month-end because there is nothing left to run. The work the run used to do has already happened, one payment at a time, on arrival. This is what automated distributions means when the phrase is used precisely: not a faster batch, but the absence of one.

What happens when rent bounces

The batch world’s worst case is the ACH return that arrives after the run. The month was closed, the math balanced, the owner was paid, and now one payment inside a fifty-payment batch is fictional. Unwinding it means reopening the reconstruction and hand-editing history.

In a per-event system the return is boring, which is the point. Because each payment split as its own recorded event, a bounce reverses as its own event too: the engine posts mirror ledger entries, the same accounts and the same amounts in the opposite direction, tied back to the original. The event nets to zero. One payment un-splits itself. The other forty-nine are untouched, because they were never mixed together in the first place. And if the owner payout had already settled before the return arrived, the system raises the event as an exception to resolve instead of letting it hide in a closed month.

The steelman: some owners want one predictable monthly deposit

This is the strongest argument for the batch, and it is a fair one. Plenty of owners plan around a single deposit: it lands before the mortgage autopay, it makes their own bookkeeping simpler, and a retiree living on rental income may genuinely prefer one number on one day to a trickle of partial payments. If per-payment distribution meant spraying money at owners the moment each tenant pays, the batch would be defensible.

But look at what the preference is actually about. It is a payout preference, not an accounting architecture. Wanting money delivered on a schedule is not the same as wanting the books to stay unresolved until that schedule. In a per-payment system the split is computed and recorded on arrival, and the delivery of the owner’s money is a separate decision layered on top. Review mode makes that hold explicit: distributions are computed the moment rent lands, then held in a queue where the manager can inspect every line, edit a fee or a withholding amount, and approve before any money moves. Approve daily, weekly, or once a month on the day your owners expect. The owner who wants one predictable deposit gets one. The ledger never waited for it, and neither did the manager’s Saturday.

How to pay property owners faster

If you searched that phrase, notice that most answers optimize the batch: better export templates, a cleaner spreadsheet, a faster payment file. Those shave hours off a process that should not exist. The structural answer is to move the split to the moment of payment, so speed stops being something you do and becomes something the system is. Start by making the fee math mechanical instead of remembered: the free property management fee calculator shows the fee and owner net for any rent and rate. Then read how the full flow works as policy in the guide to automated owner distributions: fee, withholding, reserves, and splits resolved per payment instead of per month.

Picture the last business day of next month. In one version, you are in the spreadsheet at 7 p.m., resolving a split for a duplex that changed hands in March, hoping nothing bounces after you hit send. In the other, the month is already distributed, because every payment in it was distributed the day it arrived, and month-end is just a day. Same properties. Same owners. Same rent. The only difference is when the software asked whose money it was.