Why ERPs Still Leak CAM Revenue (And How to Catch It)

Account code flexibility without verification

ERPs allow AP clerks to code an invoice to any account in the chart of accounts. The system has no knowledge of whether an HVAC replacement is a capital asset under the lease's capital exclusion or a recurring maintenance expense. A $38,000 chiller coil replacement coded to account 6215 (HVAC Maintenance) flows directly into the CAM pool. The ERP has done exactly what it was designed to do — record the transaction — but it has no way to flag that the lease excludes capital improvements above $15,000.

This isn't a user error. It's a structural gap: the ERP's data model separates accounting from lease management. Lease terms live in one module; invoice coding lives in another. Unless someone manually cross-references every coding decision against the lease, mismatches are invisible until a tenant auditor finds them.

Gross-up requires manual configuration per lease

Gross-up — the adjustment that normalizes variable expenses to a defined occupancy threshold — is typically set up as a per-lease configuration in Yardi and MRI. When a lease is executed, someone must enter the gross-up threshold (90% or 95% is most common), the variable expense account codes to be grossed up, and the calculation method.

Problems accumulate over time. When a lease is amended and the gross-up threshold changes from 90% to 95%, the ERP configuration is often not updated. When variable expense account codes are reorganized during a chart of accounts restructuring, the gross-up configuration may point to old codes that no longer exist or to new codes that shouldn't be included. The system continues calculating — just on the wrong inputs.

The result is systematic underbilling. If a building runs at 78% occupancy and the gross-up threshold should be 95% but the ERP is configured to 90%, the difference in grossed-up expenses on a $500,000 variable expense pool is approximately $30,000 — across all tenants, every year.

Pro-rata denominators are entered, not verified

The building denominator used in pro-rata calculations is entered by a data entry operator when a lease is set up. The ERP calculates pro-rata correctly given whatever denominator is in the system — but it cannot verify that the denominator matches the current lease abstract.

After a lease amendment that adds or removes square footage, the denominator needs to be updated. After an anchor tenant vacates and their exclusion from the denominator is negotiated out of subsequent leases, the denominators for those leases need to be updated. After a building expansion adds rentable area, all affected leases need new denominators.

These updates require manual intervention. When they don't happen, tenants in the same building run on different denominators that no longer reflect the same building. One tenant's pro-rata might be calculated on 48,500 SF; another's on 50,200 SF. Neither is necessarily wrong by the terms of their specific lease, but the inconsistency raises audit flags and signals that at least one denominator has drifted from its lease definition.

No cross-tenant consistency checks

ERPs calculate each tenant's CAM obligation independently. This is correct for billing purposes — each lease has its own terms. But it creates a blind spot: there is no system that asks whether two tenants in the same building are being calculated on consistent assumptions.

Tenant A's lease was abstracted in 2019 with a 50,000 SF denominator. Tenant B's lease was abstracted in 2023 after a building remeasurement showed 51,200 SF of rentable area. The ERP records both values without flagging the discrepancy. From a billing standpoint, both tenants are billed correctly per their respective lease terms. But in a portfolio audit, an attorney will ask the property manager to explain why Tenant A is being charged CAM on a 50,000 SF building while Tenant B is charged on a 51,200 SF building.

Cross-tenant consistency is a verification problem, not a transaction recording problem. ERPs are not designed to perform it.

Cumulative CAP banks require manual tracking

A cumulative CAM cap allows unused cap capacity to carry forward. If a lease has a 5% annual cap and expenses only increased 2% in year one, the landlord can theoretically recover up to 8% in year two (the 3% unused capacity plus the 5% current cap).

Most ERPs do not automatically track cumulative cap banks. The bank balance is typically maintained in a separate spreadsheet or, in well-implemented setups, in a custom ERP field that someone must update each year. When the spreadsheet is lost, when a property manager transitions off the account, or when the ERP field isn't updated, the cap bank balance is wrong. The tenant is billed using an incorrect base, and the error compounds annually.

In an audit, a tenant can demand the full cap bank history from lease commencement. If the records show that the cap was applied to the wrong base amount in years 2 through 5, the cumulative adjustment can be substantial — and the landlord bears the burden of proof.