Bulk Internet Billing for MDUs: Why Your Rent Roll and Your RADIUS Server Never Agree

Why bulk internet billing breaks every tool it touches

It is the fourth business day of the month. Your billing analyst has nine browser tabs open. Three property managers have emailed a rent roll export from Yardi, two sent PDFs out of Entrata because that is what their regional asked for, one sent nothing and will not answer, and one sent a spreadsheet where the unit numbers are formatted as 04-B in some rows and 4B in others. She is matching those against a list of doors that your RADIUS server thinks are authorised, because that is the only other place occupancy is recorded. The bulk invoice for a 312 unit community goes out today and it has to say a number of billable doors that the asset manager will check against his own rent roll before he pays it.

Nobody designed this. It accreted. The ISP billing platform came first, because you started as a small operator and Sonar or Splynx handled subscriber invoices fine. Then the bulk deals arrived and bulk is not a subscriber, it is a contract with a building. Then residents started buying speed upgrades on top of the bulk tier, which is a subscriber again, except the property owner takes a cut of it and the cut is different at every property. So the upgrade revenue lives in a Stripe dashboard, the bulk revenue lives in QuickBooks as a manual invoice, the door counts live in a spreadsheet, and the network's view of who is allowed online lives in a RADIUS database that nobody reconciles against any of it.

The specific leak we see in this business is not fraud, it is drift. Doors that turned over months ago are still authorised on the network and still counted as vacant on the invoice. Upgrade plans that a resident cancelled by moving out keep charging a card until it declines. Revenue share owed to the owner gets computed from the upgrade report rather than the collected amount, so you pay share on refunded money. Across MDU operators we have worked with, the reconciliation itself consumes two to five days of a finance person's month, and the corrections that follow the owner's dispute consume more.

Problem 1: occupancy is a moving number and your invoice is a snapshot

A bulk agreement almost never says a flat fee for the building. It says a rate per occupied unit, or per unit with a floor at some occupancy percentage, or a rate that steps down as the property lease up crosses a threshold, or a rate per door with vacancy credits capped at a number of units per month. Every one of those needs the occupancy number to be defensible on a specific date, and the only authority on occupancy is the property manager's system, which you do not control.

Standard ISP billing platforms model a subscriber with a service address. They do not model a building with a contract, an owner, a rent roll feed and a door count that changes daily. So the workaround is a monthly file, which means your invoice is computed from a snapshot that was already stale when it was exported, and any dispute turns into two people comparing spreadsheets from different days.

What a custom build does: treat the property management system as an integration, not an email attachment. Yardi, RealPage, Entrata and AppFolio all expose a way in, whether that is an API, an SFTP drop or a scheduled report. The build normalises unit identifiers per property, because 04-B and 4B being the same unit is a mapping problem you solve once per building instead of every month. Then occupancy becomes a daily event stream rather than a monthly number, so the invoice is computed from the contract's own definition of a billable door on the contract's own measurement date, and every line can be expanded to show which units it counted. When the asset manager disputes a count, you send him the unit list, not an argument.

Problem 2: every property contract encodes a different revenue share

One owner takes a percentage of gross upgrade revenue. Another takes a percentage of net after payment processing. A third takes a fixed door fee plus a share above a revenue threshold, measured annually, with a true up. A fourth negotiated a marketing amenity fee that is not revenue share at all but gets paid out of the same pool. A fifth has an escalator on the bulk rate tied to a published index on the contract anniversary. You have forty properties and roughly twelve genuinely different commercial constructs among them.

Single Digits, Sonar and Splynx all handle plans, taxes and invoices competently. None of them is a contract engine. Their model is subscriber to plan to invoice, and revenue share to a third party against a slice of that revenue on terms that differ per building is not in the data model. So the calculation happens in a spreadsheet, once a month, by one person, and the errors are found by the owner rather than by you.

What a custom build does: model the contract as a first class object with versioned terms and effective dates, then compute owner distributions from actual collected cash rather than billed amounts. That single choice, computing share on collections and clawing back on refunds and chargebacks, is usually worth more than the rest of the module, because it stops you paying share on money you never kept. Escalators run on the contract anniversary automatically and produce a notice document. Renewals and expiry dates surface as a queue rather than as a surprise. When a contract term is genuinely one of a kind, it lives in the contract record with its own rule, not in a comment field somebody will not read next year.

Problem 3: the network does not know a resident moved out

A resident moves out on the 28th. Her upgrade plan keeps billing. Her devices stay authorised on the wireless network for weeks, or if you are careful, someone manually deauthorises her and occasionally deauthorises the wrong unit. The new resident moves in on the 1st, calls support because the network wants a portal login she does not have, and your tech spends twenty minutes creating something that should have existed before she picked up the keys.

This is not a billing bug, it is a missing event. The move in and move out are recorded in the property management system, and nothing downstream listens. That is the whole gap. Every operator we have talked to in this space has a version of it, and most have papered over it with a support process rather than a system.

What a custom build does: make move in and move out into events that fan out. A move in provisions the unit, pre creates the resident account, generates a credential or a device onboarding path, and starts the bulk clock if the contract counts occupied doors. A move out stops the upgrade subscription with a prorated final charge, releases the network authorisation on the contract's own schedule rather than immediately, because the resident may still be in the unit for a few days, and flags the unit for a vacancy credit if the agreement allows one. On the network side this is RADIUS or the controller API for whatever gear is deployed, Ruckus, Cambium or UniFi being the common three in this market, and the build has to tolerate a property where the gear is different from every other property in the portfolio, because there is always one.

Problem 4: the owner wants a report you cannot produce

Asset managers at institutional apartment owners are increasingly treating connectivity as an amenity with a return, which means they want numbers: take rate on upgrades by floor plan, support ticket volume per hundred doors, uptime by property, revenue share year to date against pro forma. What they get today is a PDF you assemble in a spreadsheet the week they ask.

There is a compliance dimension too. The FCC's 2022 order on exclusive access in multiple tenant environments restricted certain graduated revenue sharing arrangements and required exclusive marketing arrangements to be disclosed to tenants. Whether a specific clause in your portfolio is affected is a question for counsel, not a blog, but the operational consequence is the same either way: you need to be able to say what every property contract actually contains without opening forty PDFs.

What a custom build does: give each owner a portal scoped to their properties, with the numbers computed from the same data the invoice used so they can never disagree. Then the contract terms are structured data, so a question about which properties carry a graduated share is a query rather than a legal review project. Operators who ship this find it changes renewal conversations, because the owner is arguing against his own dashboard rather than against your spreadsheet.

What a bulk internet billing build costs and how long it takes

From Digital Heroes delivery work across two thousand plus projects, here is the honest shape for this category. A first release covering property management system integration and occupancy sync, bulk invoicing against structured contract terms, resident upgrade billing and collections based revenue share runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding provisioning and deprovisioning driven by move events, the owner portal, support agent tooling, dunning and payment operations, and reporting runs $180,000 to $450,000 phased over 7 to 12 months.

What drives cost up in this specific business: the number of distinct property management systems in your portfolio, because Yardi and RealPage are two projects not one, and a property that will only send you a PDF is a third. The number of network gear vendors across the portfolio, since each controller API is its own integration and the acquired properties always run something odd. Tax, if you have doors in enough jurisdictions that communications tax becomes real, at which point you are integrating a tax engine rather than writing rules. And migration, which in this business means loading historic contracts as structured terms, and that is manual reading time nobody enjoys and nobody can skip.

What keeps cost down: starting with your top ten properties by revenue and the two property management systems that cover most of them, and leaving the awkward tail on the existing process for a release or two.

When Single Digits, Sonar or Splynx is the right answer

Buy if bulk is a small part of what you do and your bulk deals are flat per door with no share and no occupancy tie. Splynx and Sonar are solid ISP billing platforms, they handle plans, taxes, dunning and subscriber lifecycle properly, and if your commercial model fits their shape you should not be paying an agency to rebuild them. Single Digits is purpose built for managed WiFi in this market and will save you time if your portfolio looks like the portfolio they designed for.

Our position on when to build: when two or more of these are true. Your bulk contracts contain more than about four genuinely different commercial constructs. Occupancy drives your billing and you get it as a monthly file. Owners take revenue share and you compute it manually. You have more than one property management system and more than one network vendor. Or you are being asked for owner reporting you cannot generate without a person assembling it.

The tipping point is not door count on its own. It is that this business is a contract business wearing an ISP costume, and ISP billing platforms model subscribers, not contracts with buildings. Once the contract layer is where your margin actually lives, keeping it in a spreadsheet means your margin lives in a spreadsheet.

How to choose a developer for MDU billing software

Ask them to model your commercial terms on a whiteboard before you sign. A developer who has done this draws property, contract with versioned terms, unit, occupancy event, resident account, upgrade subscription and owner distribution, and knows that the distribution has to reference collections rather than invoices. Someone who draws customer, plan and invoice has built a SaaS billing app and is about to discover MDU on your budget.

Ask specifically how they handle a unit identifier that does not match between the rent roll and your network records. If the answer is that the property manager should fix their data, walk. The correct answer is a per property mapping layer with a human review queue for unmatched units, because that mismatch is permanent and you will live with it forever.

Ask what they have actually integrated, by name. Yardi via API and Yardi via SFTP report drop are different work. RealPage, Entrata and AppFolio are each their own onboarding conversation. RADIUS is not the same as a controller API. Insist on named systems, not the word integrations.

Ask who owns the code, the repository and the cloud accounts, and get it in the contract before kickoff, not in a schedule at the end. At Digital Heroes it is yours from the first commit, and any firm that hedges on this is selling you a dependency. Start by exporting one property's rent roll and one month of your upgrade revenue, and asking a developer to walk you through exactly how they would compute that property's invoice and the owner's share from those two files. The answer tells you everything.