MDU Bulk Internet Billing Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the scope get written around subscribers instead of contracts?

Bulk internet operators almost always brief this as a billing project, and billing projects get specified the way billing products are built: a customer, a plan, an invoice. That model is correct for the resident who buys a speed upgrade. It is wrong for the thing that carries most of your revenue, which is a contract with a building.

The consequence shows up around the first invoice run. The system can bill a resident and cannot express a rate per occupied unit with a floor at a given occupancy percentage, an escalator on the contract anniversary tied to a published index, vacancy credits capped at a number of units per month, and an owner distribution on terms that differ at every property. So somebody rebuilds it in a spreadsheet, and the spreadsheet becomes the truth again.

This is specific to multiple dwelling unit connectivity because the commercial construct sits above the subscriber rather than beside it. In a normal internet service business the contract and the subscriber are the same entity. In yours, one contract governs several hundred doors, some of which pay you directly, and the owner takes a slice that spans both revenue streams.

The fix is to make the contract a first class object with versioned terms and effective dates before anything else is designed. Ask a developer to draw property, contract with versioned terms, unit, occupancy event, resident account, upgrade subscription and owner distribution, and to say out loud that the distribution references collections rather than invoices. If they draw customer, plan and invoice, they have built a billing application and are about to learn your industry at your expense.

What goes wrong when you migrate rent roll and unit data?

Unit identifiers are the whole problem and they never stop being the problem. The rent roll says 04-B. Your network records say 4B. A third property writes it as B04. Within one property, the same export sometimes uses both formats depending on which staff member created the record. Nobody at the property management company considers this a defect, because to them it is obviously the same apartment.

The second migration trap is contract history. Loading forty existing property agreements as structured terms means a person reads forty documents and encodes escalators, occupancy definitions, credit caps and share formulas. That is reading time, it cannot be automated away, and it is almost never in the estimate.

The fix is a per property mapping layer with a human review queue for unmatched units, built as a permanent feature rather than a migration script. Any developer who suggests the property manager should fix their data has not worked in this market, because that mismatch is permanent and you will live with it for the life of the account. Then treat contract migration as a funded phase with a named owner and a schedule, and start with the ten properties that carry most of the revenue rather than trying to load everything at once.

Why do property management and network integrations break after launch?

Occupancy feeds fail quietly. Yardi through an interface and Yardi through a scheduled report drop are different projects, and RealPage, Entrata and AppFolio are each their own onboarding conversation with their own approvals, their own credentials and their own regional contact who has to authorise access. The build gets tested against two of them and the rest arrive later under pressure.

Then the breakages start. A property manager changes their export template because a regional asked for an extra column. Credentials rotate during an unrelated audit. A property gets sold and the new manager uses a different platform entirely, which is not a bug but is definitely a project. The worst case is a feed that keeps arriving while silently omitting units, so your door count drifts down and your invoices under bill until somebody notices months later.

Network integration fails on variety. Ruckus, Cambium and UniFi are the common gear in this market and there is always one acquired property running something else, with a controller interface nobody documented. Authorisation state drifts out of alignment with billing state and no alarm sounds, because nothing is comparing the two.

The fix has two parts. First, monitor every feed for shape, not just arrival: expected unit count, expected change volume, and an alert when a property's occupancy moves more than a threshold in a day. Second, run a scheduled reconciliation between billing state and network authorisation state and surface the differences as a work queue. Those differences are where authorised devices for departed residents live, and they are worth money.

What happens when move in and move out events are not covered?

This is not a billing bug, it is a missing event, and almost every operator has a version of it. A resident moves out on the 28th. Her upgrade plan keeps billing. Her devices stay authorised on the network for weeks. The new resident moves in on the 1st, calls support because the portal wants a login she does not have, and a technician spends twenty minutes creating something that should have existed before she picked up the keys.

Most operations have papered over this with a support process rather than a system, which means it depends on somebody remembering. It also means the failure is invisible in aggregate: nobody can tell you how many authorised units are occupied by people who left, because no report joins those two facts.

The fix is to 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 device onboarding path, and starts the bulk clock where the contract counts occupied doors. A move out stops the upgrade subscription with a prorated final charge, releases network authorisation on the contract's own schedule rather than instantly since residents are often still in the unit for a few days, and flags the unit for a vacancy credit where the agreement allows one. Every one of those steps should be visible as a task with an owner when it fails, because it will fail for the property that only sends PDFs.

Should you build custom or configure what you already own?

Some operators should not build, and it is worth being direct about who. If bulk is a modest part of what you do and your bulk deals are flat per door with no revenue share and no occupancy tie, Splynx and Sonar are solid platforms that handle plans, taxes, dunning and subscriber lifecycle properly, and paying an agency to rebuild them is poor use of capital. Single Digits is purpose built for managed connectivity in this market and will save you real time if your portfolio resembles the one it was designed for.

Build when two or more are true. Your bulk contracts contain more than about four genuinely different commercial constructs. Occupancy drives billing and you receive it as a monthly file. Owners take revenue share and you compute it by hand. You run more than one property management platform and more than one network vendor. Or owners are asking for reporting you cannot produce without a person assembling it.

The tipping point is not door count. It is that this is a contract business wearing an internet service provider costume, and platforms that model subscribers cannot hold the layer where your margin lives.

How do hidden costs get into the quote?

The first is platform count. Yardi and RealPage are two projects, not one, and a property that will only send a PDF is a third. Ask for a per platform rate and count the platforms actually in your portfolio today, including the one property everyone forgets.

The second is contract migration, covered above. It is reading, it is slow, and it is usually assumed to happen in the background.

The third is network vendor variety. Each controller interface is its own integration, and acquired properties always run something odd. Get the full equipment list from your field team before quoting, not from memory.

The fourth is tax. If you carry doors across enough jurisdictions that communications tax becomes real, you are integrating a tax engine rather than writing rules, and that is a different scope with an ongoing subscription attached.

The fifth is payment operations. Dunning, retries, chargeback handling and refunds sound like a payment processor's job until you realise every one of them has to flow back into the owner distribution calculation. That is the link that makes collections based revenue share work, and it is where a cheap quote turns expensive.

Ask for the estimate broken into engineering, property platform integrations, network integrations, contract migration and payment operations, each with an owner and a date.

What separates a build that works from one that fails here?

The test is whether an asset manager can dispute an invoice and lose in one email. That means every billed line expands into the specific unit list it counted, on the contract's own measurement date, using the contract's own definition of a billable door. When you can send the unit list instead of an argument, disputes stop being a monthly ritual.

The second determinant is computing owner distributions from collected cash with clawback on refunds and chargebacks. Write it into contracts where you can, and make the system compute it that way regardless. This single decision is usually worth more than the rest of the module and it is the easiest thing to get wrong, because the obvious data source is the billing report.

Third, structured contract terms pay for themselves beyond billing. Regulatory attention to arrangements in multiple tenant environments means you may be asked which properties carry which terms, and answering that from structured data is a query rather than a review of forty documents. Whether a specific clause in your portfolio is affected is a question for counsel, but being able to answer quickly is a software decision you make now.

Finally, settle ownership before kickoff: the repository, the cloud accounts and the right to hire anyone else. Your contract terms and payment history are the record of the business, and they should not sit in a system you cannot leave.