Telecom Site Lease Software: How Long Have You Been Paying Rent on Sites You Already Left?

Why a site lease portfolio leaks money quietly and continuously

A carrier decommissioned a rooftop site in 2021 during a consolidation. The RF team removed the equipment. The construction project closed. Nobody sent the termination notice inside the window the lease required, so the term auto renewed, and the accounts payable file kept a monthly payment running against a landlord in a market the carrier no longer serves. Three and a half years later a lease audit finds it. On the other side of the same portfolio, a tower company discovers that a carrier added a second sector to a monopole in 2023 under an amendment that was signed, filed, and never entered into billing, so eighteen months of colocation revenue was never invoiced. Neither of those is a system failure in the dramatic sense. They are both the same failure: the agreement lives in a PDF and the money lives in a payment file, and nothing continuously reconciles the two.

The stack is usually a document repository holding scanned leases and amendments, a spreadsheet or a lease module in the ERP (Enterprise Resource Planning) driving payments, a project tracking tool such as Sitetracker or Accruent Siterra for deployment, a GIS layer, and the site acquisition team's own records. Those products are real. Sitetracker is genuinely strong on deployment programme management. Siterra has deep site lifecycle heritage. Tarantula is built for tower portfolios specifically and knows the colocation model. The recurring gap is that deployment systems are built around a project, which ends, while a site agreement is perpetual and its obligations continue for decades after the project team disbanded.

In the contract portfolio work we have delivered, the money is always in the same four places: rent still paid after decommissioning, escalations applied from an interpreted rather than modelled clause, colocation and revenue share never billed, and duplicate payments where an assignment created a second payee record. None of that needs analytics to find. It needs the lease terms to exist as data.

Problem 1: the lease is a document, and abstraction is the entire project

Everything downstream depends on turning agreement language into structured, testable terms: commencement, initial term, renewal structure and whether renewals are automatic or elective, notice period and notice method, base rent, escalation mechanism, revenue share, assignment and consent, access rights, restoration obligations, and the exclusivity or interference clauses that constrain who else you may put on the structure. Most portfolios have this partially done, in a spreadsheet, by whoever ran the last acquisition diligence.

What a custom build does: abstraction is a first class workflow, not a data entry task. Each abstracted term links to the specific document and page it came from, carries a confidence and a reviewer, and gets a second pass on anything that drives money. Document extraction earns its keep here on volume: models read the scanned lease and the amendment chain to propose values for the standard terms, and a human confirms them against the linked page. That converts a two year manual programme into a few months of review, which is usually the difference between the project happening and not happening. What it does not do is let you skip the human. An escalation clause misread by a model becomes thirty years of wrong payments.

The amendment chain is the part that defeats spreadsheets. A site with a 1998 ground lease, a 2004 assignment, three amendments, a memorandum of lease, and a 2019 easement is not one record. The system has to hold the document lineage and compute the current effective terms from it, with the ability to show which instrument set each term.

Problem 2: escalations are language, not a percentage field

A payment engine that stores an escalation rate of three percent will be wrong on a large share of any real portfolio. Escalators come as fixed percentage annually, fixed percentage every five years on the anniversary, index linked with a floor and a cap, greater of a fixed rate or an index change, and blended structures that change at renewal. Index linked clauses reference a specific published series, sometimes a regional one, sometimes with a stated base month, and they lag publication.

What a custom build does: model the escalation as a rule, not a number. The rule holds a type, a frequency, an anniversary basis, an index reference where applicable, floors and caps, and a rounding convention, because rounding is a genuine source of dispute. The engine then generates a payment ledger years forward, which lets treasury forecast and lets an auditor test any payment against the clause. When a published index revises, the affected sites recalculate and produce a variance list rather than a silent adjustment. The prize here is not accuracy in the abstract. It is that a landlord dispute becomes a two minute answer with the clause, the index value, and the arithmetic on one screen.

Problem 3: colocation amendments create revenue that nobody invoices

For a tower company or neutral host, the revenue event is a carrier adding or modifying equipment. That event begins as an RF request, becomes a structural analysis, becomes a permit, becomes a construction notice to proceed, and becomes an amendment with a new monthly rate and a commencement tied to installation or to a date. The billing trigger sits at the end of a chain owned by engineering and construction, and it reaches finance by email if it reaches finance at all.

What a custom build does: make the amendment the billing object and tie its commencement to a verifiable event in the same system, the notice to proceed or the confirmed installation date. Once the milestone lands, billing starts automatically and the delta from the prior rate appears in a revenue change report. Ground lease revenue share works the same way in reverse: if the underlying landlord is owed a share of colocation revenue, that obligation should be derived from the same amendments rather than calculated separately by a different team, because that is exactly where portfolios end up underpaying a landlord and settling later.

Add the loading question, since it is inseparable. Structural capacity determines whether the next colocation can happen, and the current structural analysis for a tower is an asset record with a date. A site record holding that analysis, the mounted equipment inventory, and residual capacity turns can we put a carrier here into a query rather than a two week engineering exercise.

Problem 4: ghost rent is a controls problem, not an accounting problem

Rent continues because nothing connects decommissioning to the payment file. The project that removed the equipment had its own system, and it closed. The lease administrator was never told, or was told and missed the notice window, which in many ground leases is measured in months before an anniversary.

What a custom build does: the site has a lifecycle status and payments are derived from it, so a site marked for decommissioning immediately creates a termination task with the required notice date calculated from the clause, an owner, and an escalation path. If the notice date passes without a notice recorded, payments continue but the system reports the failure with the cost of the missed window attached, because a number attached to a missed task changes behaviour. Payment side controls matter equally: one payee record per landlord entity with a validated payment instruction, duplicate detection across payee and site, and a hold when a change of ownership arrives, since fraudulent change of payee letters are a known problem and a manual process is what they exploit. Estoppel requests should run through the same record rather than through an inbox.

Problem 5: deployment milestones and lease obligations are one timeline pretending to be two

Site acquisition, zoning, FAA determination and antenna structure registration where applicable, environmental and historic review, permitting, construction, and on air date are usually tracked as a project. Rent commencement, escalation anniversaries, renewal windows, and access obligations are tracked as a lease. They are the same site and they constrain each other constantly: a delayed permit can push rent commencement, a zoning condition can restrict future colocation, and a landlord consent requirement can gate a construction start.

What a custom build does: one site record with both timelines attached, so the dependency is visible. A build programme can then answer the question that matters to a CFO, which is not how many sites are in construction but what committed rent is running against sites not yet generating revenue. Deployment tools alone cannot answer that because they do not hold the money. Lease systems alone cannot answer it because they do not hold the schedule.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, here is the honest shape. A focused first release, meaning the site and agreement model with amendment lineage, abstracted terms, the escalation and payment engine, lifecycle status with termination control, and payee controls, runs $80,000 to $160,000 in 14 to 20 weeks. A full platform adding colocation and revenue share billing tied to deployment milestones, equipment inventory, permit records, a landlord portal, accounting integration, and portfolio analytics runs $200,000 to $500,000 over 9 to 15 months.

What drives price up specifically in site portfolios: the abstraction backlog, because thirty thousand documents is a programme of its own even with extraction assistance, and it is the item most often left out of a budget. Accounting integration, since lease accounting treatment has rules of its own and finance will not accept an approximation. The number of agreement archetypes, as portfolios assembled through acquisitions carry drafting traditions that do not normalise cleanly. And multi jurisdiction operation, which changes indexation, notice, and tax handling.

What keeps price down: abstracting only the terms that drive money first, meaning rent, escalation, term, renewal, notice, and revenue share, and leaving the wider clause library for a later pass.

Build versus buy, and when buying is clearly right

Buy if you hold under roughly 500 sites, or if your dominant problem is deployment programme management rather than lease economics. Sitetracker is a strong product for running a build programme and Tarantula understands tower portfolios properly. If what you need is visibility into a rollout, buy the rollout tool.

Build when two or more of these are true. Your portfolio came together through acquisitions and no two tranches share a data model, so normalisation is your actual project. Colocation or revenue share billing depends on events owned by engineering and reaches finance manually. You have found ghost rent or missed escalations in an audit and the finding was material. You are a landlord facing counterparty at scale, meaning thousands of individual property owners who each expect a correct payment and an answerable statement. Or you are competing to acquire portfolios, where the speed and accuracy of diligence abstraction is a commercial advantage rather than back office work.

How to choose a developer for site lease and deployment software

Ask them to model the agreement before you sign. You should see site, structure, agreement with document lineage across amendments and assignments, effective term computed from that lineage, escalation rule, payment schedule, and lifecycle status driving payments. If they draw properties and leases with a rent field, they will build a rent tracker and your escalation clauses will be flattened into a percentage.

Ask how they would handle an index linked escalator with a floor, a cap, and a lagged base month. The answer tells you within a minute whether they have modelled financial terms before.

Ask what they have integrated. An ERP payables interface, a lease accounting treatment, and a deployment tool are three different problems. Ask for the specific system and direction of data flow.

Ask who owns the code and the abstracted lease data, in writing, before kickoff. The abstraction output is an asset in its own right and often the most valuable thing the project produces. At Digital Heroes the client owns the code and the data from the first commit.