Preparing for monthly owner draws used to take our financial controller hours.

The Buildium Page That’s Almost Always Right — Except When It Isn’t

Buildium’s “Owner draw by EFT” page shows a number for every property called Available for payment. At my company RL Property Management, that page is 624 rows long. And for a chunk of them, the number Buildium proposes is the wrong amount to send the owner.

Not because Buildium’s math is broken, but because Buildium doesn’t know what our team knows about owner funding requests.

When an owner sends us $8,000 to fund a turnover, that money lands in the trust account and immediately shows up as cash available to disburse. If nobody catches it, we pay the owner’s own turn money right back to them on the 10th, then have to ask for it again. Same story for draws that should be held while a project wraps up.

We track all of that in an Airtable table called Funding Requests, and our controller, who runs our disbursements, has been reconciling Buildium against Airtable by hand before she pays anyone. It takes hours.

Last week I replaced that manual reconciliation with a script. It took one afternoon with Claude Code.

What the Job Does

At 6 AM on the 10th of each month, a small Python script runs on our server and:

  • Pulls every active property and owner from the Buildium API, along with GL balances, reserves, and unpaid bills. About a dozen API calls, 20 seconds total.
  • Rebuilds Buildium’s “Available for payment” figure for each property.
  • Subtracts unpaid bills.
  • Pulls the open funding requests from Airtable and subtracts the owner-funded money that’s still earmarked for work.
  • Writes it all to a Google Sheet, one tab per run, grouped by owner exactly like Buildium’s page, and pings our controller and me on Slack with the link.

Rows where the adjusted amount differs from Buildium’s default turn yellow. Everything else is pay as-is.

On the first run, 61 funding requests accounted for roughly $296,000 of owner money that would otherwise have been paid right back out. That’s the size of the problem this thing catches every month.

The Airtable Side

Our Funding Requests data, which lives in Airtable, has one row per request: a status (Sent, Received Funds, Complete, Cancelled), the amount requested, a “Hold Draw” checkbox, and an optional withholding amount. The rule the script applies is simple:

  • A request counts if the funds have been received, or if Hold Draw is checked.
  • Hold back the withholding amount if someone filled it in; otherwise hold back the full amount requested.
  • Never let the payout go below zero.

Every request has to match a Buildium property by ID (we store Buildium’s property ID on each Airtable property, and a separate monthly job keeps that current). No fuzzy name matching. If a request can’t be matched, it lands on a Summary tab for a human to look at instead of silently disappearing.

That last rule is doing more work than it looks like. Matching by owner name or property address breaks the first time someone renames a unit or an owner has two similarly-addressed properties. Matching on an ID that never changes — with a fallback that surfaces mismatches instead of hiding them — is what makes this the kind of automation you can actually trust with real money, instead of one you have to quietly double-check anyway.

How It Was Built

I did this with Claude Code using Fable 5.1, and it was basically a one-shot. I described the goal, it read the code from my earlier Buildium projects (a weekly trust-account check, a monthly reserve sync, a daily bill checker), we agreed on a plan, and then it did a bunch of computer and coding stuff that I’m mostly ignorant of. Done. My contribution was answering questions about business rules, like what “Hold Draw” should do to the number.

That’s worth pausing on. Claude Code already knew how we talk to the Buildium API, because it had read three earlier projects built on the same patterns. Each automation makes the next one faster to build.

What This Means for You

These tools have gotten insanely cheap and fast. Your PM software’s API, if you have access, probably exposes more than you think. Pick the monthly ritual that you hate doing the most, or sucks up the most time, and start there.

-Peter