Shopping centre data analytics with AI started with three questions from the technology director of a large Baltic shopping centre: can tenant and footfall data become monthly insights automatically, can leases be processed without re-typing, and can energy and maintenance data support cost decisions? Taking them in that order showed they all need the same missing thing: one row per unit per month that carries the lease clause, the consumption and the sales. We built that row, starting from the leases.
The problem: eight systems, eight names for one shop
A shopping centre with 170 units runs on specialist systems, and each does its job well: a document archive for leases, a finance system for invoices, a website directory, footfall counters, a monthly sales report from tenants, parking plate recognition, a marketing platform and an energy monitoring system.
The same fashion shop appears in each of them under a different key: a unit number and legal entity in the lease, a customer account in finance, a marketing slug on the website, a zone in the footfall counter, a trading name in the tenant’s sales report, and a meter or air-handling unit in energy data. No two are the same string. That is why a “monthly insight” never assembles itself.
The leases add a second problem. They are in Latvian, while finance and group reporting work in English. A lease says what the rent was; an amendment signed two years later says what it is. A tool that reads one and not the other is wrong before it starts.
What we built
- Leases and amendments read together. The system reads the Latvian lease and every amendment and produces English fields: parties, unit, area, term, base rent, payment day, indexation index and date, turnover rent rate, service-charge basis and cap, break and renewal options, deposit.
- Three states, no silent defaults. Every field is either read from a clause (click to see the sentence), derived by a formula shown next to it (monthly rent = area × rate; notice deadline = break date − notice period), or explicitly marked “not stated in this lease”. Nothing is guessed and left looking like a fact.
- The money view. From the lease file the system checks four things: indexation that was never applied (which compounds, because every later indexation starts from the lower base), turnover rent above the breakpoint that was never invoiced, tenants whose missing sales reports make turnover rent impossible to assess, and notice and option deadlines that exist only in the PDF.
- Buckets kept apart. Revenue not billed, cost absorbed by design in a negotiated clause, and rent under notice pressure are shown separately and never added together, so every figure stays trustworthy.
- Energy and maintenance tied to the lease. The service-charge basket is compared with what each lease allows the landlord to recharge, split into costs absorbed by design (a negotiated cap) and costs absorbed by silence (a clause nobody wrote).
What changes for the team
| Before | With the lease data row | |
|---|---|---|
| Current rent | In the lease or in a later amendment, whichever someone found | Read from both, with the superseded value shown |
| Indexation | Applied if someone remembered | Every missed application listed with its effect |
| Turnover rent | Depends on a percentage buried in a PDF | Rate and breakpoint beside the reported sales |
| Break and renewal notices | Dates inside documents | Deadlines calculated and listed by days left |
| Service charges | Disputes reveal what the lease excludes | Recoverable and non-recoverable costs visible per lease |
| Monthly insight | Four centre-wide averages from published totals | Per-unit metrics once the row joins the systems |
Where people stay in control
When a clause cannot be read with confidence, for example “rent is indexed by mutual agreement”, with no formula and no index named, the system does not extract a value. It marks the lease for human review and says why.
We were also honest about the hardest part. Footfall is almost always counted by zone rather than by shop, and a turnover percentage that lives in a PDF cannot meet a sales figure that lives in an inbox until one system is chosen as the key to join on. That decision belongs to the centre, and it comes before any dashboard.
Where else this works
- Logistics and office portfolios: leases turned into ERP fields and deadline tasks on signing day.
- Retail chains as tenants: the same lease row, seen from the tenant’s side, to check what they are charged.
- Facility management: maintenance work orders tied to who pays for them under each contract.
Related use cases: Lease abstraction AI · AI meeting minutes and project status · AI business case for accounting firms. All Contracts & documents to data use cases · How we deliver this: Custom AI solutions
FAQ
Do we need to replace our finance or document systems?
No. The row joins the systems you already have. The first step is agreeing which system’s unit key the others map to.
Can it read leases in Latvian, Lithuanian or Estonian?
Yes. The source language stays as it is; the extracted fields come out in the language your finance and reporting use.
Why not show one total of money found?
Because money not billed, money given away on purpose and money merely at risk are different things. Adding them together is how a number stops being trusted.
Want to see one of your leases and its amendments as a single data row? Talk to us