Tower Site Lease Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does lease abstraction get left out of the plan?

Because it does not look like software. The build has a shape everyone recognises: a site model, a payment engine, escalation rules, a portal. Abstraction looks like typing, so it gets assigned to whoever has capacity, usually a lease administrator who already has a full renewal calendar, and it quietly becomes the critical path.

The reason it matters more here than in most contract portfolios is that nothing downstream is testable without it. An escalation engine with no abstracted escalation clauses cannot be validated. A termination control with no notice periods cannot fire. A colocation revenue rule with no revenue share terms is a form. So the software finishes, the data does not, and the team keeps working the way it did before, which is the single most common way these projects fail without anybody calling them failures.

The fix is to scope abstraction as its own workstream with its own budget line, and to sequence it by money rather than by site number. Abstract only the terms that drive cash first: commencement, term, renewal structure, notice period and method, base rent, escalation mechanism and revenue share. Leave the wider clause library, meaning access, restoration, exclusivity and interference, for a later pass. Document extraction is genuinely useful at this volume, proposing values from the scanned lease and the amendment chain with each proposal linked to its source page, but a human still confirms anything that drives money, because an escalation clause misread by a model becomes decades of wrong payments.

What goes wrong when you migrate agreements and payee records?

Two things, and both come from portfolios assembled through acquisitions.

The first is amendment lineage. A site with a 1998 ground lease, a 2004 assignment, three amendments and a 2019 easement is not one record and cannot be flattened into one. Migrations that load the most recent document as the agreement lose the ability to show which instrument set which term, which is exactly what you need in a landlord dispute or in refinancing diligence. The model has to hold the documents in sequence and compute effective terms from them, with every term traceable to the instrument that created it.

The second is payee identity. The same landlord entity appears three times after two assignments and a change of trustee, with three payment instructions and three payment streams. That is how duplicate payments happen, and it is also the gap that change of payee fraud exploits, because a fraudulent letter arriving into a manual process looks exactly like the legitimate assignments you receive every month.

Migration is the right moment to fix both. Entity resolution across landlord records, proposing merges from name, address, tax identifier and payment overlap with a human confirming each, is real work and belongs in the plan. So does a rule that any payment instruction change, whenever it arrives, places the site on hold until verified through a channel you initiated rather than one supplied in the letter.

Why do accounting and deployment integrations break after launch?

Because the two systems on either side of a lease platform have different clocks. Finance closes periods and will not accept an approximation, and deployment tools are built around projects that end.

The accounting side breaks on treatment rather than on transport. Posting a payment is straightforward. Posting it with the right lease accounting treatment, with deferral where it applies, is not, and a build that scopes an accounts payable interface without agreeing treatment with finance first will produce a reconciliation argument in the first close after go live. Get the posting rules signed off by your controller before development, in writing, with example journals.

The deployment side breaks on lifecycle mismatch. Sitetracker and Accruent Siterra are real products and Sitetracker in particular is strong at running build programmes, but a project closes and a site agreement continues for decades. If your integration keys milestones to a project identifier, sites whose projects have been archived stop syncing and rent commencement dates quietly stop updating. Key everything to the site, and treat project records as attachments to it.

The third failure is index data. Index linked escalators reference a specific published series, sometimes regional, sometimes with a stated base month, and publications get revised. A build that pulls an index value once and stores it as a number cannot recalculate. Store the series, the period and the value with its publication date, and make a revision produce a variance list for review rather than a silent adjustment across the portfolio.

What happens when termination notices are not driven by site status?

You keep paying rent on sites you left. This is the most quoted failure in the category and it is not an accounting error, it is a missing control. The project that removed the equipment had its own system and closed. The lease administrator was never told, or was told and missed a notice window measured in months before an anniversary, so the term auto renewed and the payment file kept running.

The reason it recurs is that payments are usually a standing instruction with a start and no dependency. Nothing about the physical state of the site touches them. A site can be decommissioned, its steel removed and its access terminated, and the payment continues because no record connects those events.

The fix is to derive payments from a site lifecycle status rather than from a standing file. Marking a site for decommissioning immediately creates a termination task with the required notice date calculated from the actual clause, an owner and an escalation path. If the notice date passes with no notice recorded, the system reports the failure with the cost of the missed window attached, because a number next to an owned task changes behaviour in a way a reminder never does.

Run the same control in reverse for revenue. A colocation amendment should be the billing object, with commencement tied to a verifiable event held in the same system, such as the notice to proceed or a confirmed installation date, so billing starts without an email from a construction manager.

Should you build custom or configure Sitetracker or Tarantula?

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

There is a second configure case worth testing before you commission anything. Ask your incumbent to model three of your genuinely awkward escalation clauses, one index linked with a floor and a cap, one greater of a fixed rate or an index change, and one that changes structure at renewal. If they can express all three with effective dates, your problem may be abstraction and process rather than software, and abstraction is cheaper than a platform.

Build when two or more hold. Your portfolio came together through acquisitions and no two tranches share a data model, so normalisation is the actual project. Colocation or revenue share billing depends on events owned by engineering and reaches finance manually. A lease audit has already found material ghost rent or missed escalations. You face thousands of individual property owners who each expect a correct payment and an answerable statement. Or you compete to acquire portfolios, where diligence abstraction speed is a commercial advantage rather than back office work.

How do hidden costs get into a site lease software quote?

The abstraction backlog is first, largest and most often absent. Price it per agreement, with an explicit assumption about document quality, because a portfolio with a clean repository and a consistent naming convention moves several times faster than one with scanned files spread across acquisition era folders.

Accounting integration depth is second. An accounts payable interface is one number. An interface plus agreed lease accounting treatment plus deferral schedules plus a reconciliation your controller signs off is another, and finance will not accept the first as a substitute for the second.

Agreement archetype count is third. Portfolios built by acquisition carry the drafting traditions of every seller, and each archetype is its own abstraction template and its own set of edge cases. Count them before estimating, by sampling twenty agreements per acquired tranche.

Jurisdiction count is fourth, since indexation references, notice requirements and tax handling all change across borders. A multi country portfolio is not a bigger version of a single country one.

What separates a site lease build that works from one that fails?

Whether escalation is modelled as a rule or stored as a percentage. A payment engine with an escalation rate field will be wrong across a large share of any real portfolio, because escalators arrive as fixed annual increases, step increases every five years, index linked terms with floors and caps, greater of clauses and structures that change at renewal. The rule needs a type, a frequency, an anniversary basis, an index reference, bounds and a rounding convention, because rounding is a genuine source of dispute. Get that wrong in week one and you are rebuilding the core later.

The second separator is whether the engine generates a forward ledger. Payments projected years ahead let treasury forecast and let anyone test a single payment against the clause and the arithmetic on one screen, which turns a landlord dispute into a two minute answer. Systems that compute the next payment only can defend nothing.

The third is whether one site record carries both the lease obligations and the deployment timeline. They constrain each other constantly: a permit delay moves rent commencement, a zoning condition can restrict future colocation, a landlord consent can gate a construction start. Holding both lets you answer the question a chief financial officer actually asks, which is how much committed rent is running against sites not yet generating revenue.

The fourth is ownership of the abstracted data, not only of the code. The structured lease data set is frequently the most valuable thing the project produces and it supports audits, disputes, refinancing and portfolio transactions. It should sit in your accounts alongside the repository, agreed in writing before kickoff.