Process UK Landlord Demands into Multi-Site Tenant AP

A CBRE quarterly demand pack covering one slice of the estate. A JLL pack covering another. Three or four smaller managing agents' emailed PDFs for the long tail. An insurance rent demand from the landlord's broker. A credit note against last quarter's over-recovery. All due against the BACS run at the end of the week.

This article walks how to process UK landlord demands into multi-site tenant AP, end to end. The audience is the AP clerk, property accountant, or finance manager at a 20–500-site UK commercial tenant. The target AP systems are Xero, QuickBooks Online, Sage 50, Sage Intacct, NetSuite, and Dynamics 365 Business Central. The deadline is the BACS run at the end of the week.

Multi-site UK commercial tenants receive rent demands, service charge demands on account, insurance rent demands, periodic statements, and credit notes from five-to-ten managing agents per quarter. Processing them into a single AP-ready ledger requires a per-supplier schema covering supplier, property and lease reference, demand reference, service period, line-level VAT classification, sort code, and account number. That schema then maps onto each major UK AP platform's import format. VAT treatment per line anchors in HMRC VAT Notice 742A for rent and service charges under the option to tax and in the insurance exemption for insurance rent.

The operational frictions are specific. Landlord demand references collide with Xero's per-supplier invoice-number uniqueness rule. The service period sits inside the line description rather than in a structured date field. Each managing agent uses a different document template. Sort code and account number often appear on the first demand of a new lease and then disappear from subsequent demands. A single demand can bundle VAT-standard, VAT-exempt, and option-to-tax lines that the AP record has to capture at line level.

The regulatory wrappers around all of this are the RICS Service Charges in Commercial Property 2nd Edition, HMRC VAT Notices 742A and 701/36, the Landlord and Tenant (Covenants) Act 1995, and the BACSTEL-IP standard for the payment file at the end of the run. Jurisdiction throughout is England and Wales; Scotland (under the Tenancy of Shops (Scotland) Act 1949 and Land and Buildings Transaction Tax) and Northern Ireland operate on different statutory bases and are out of scope.

What follows is the document taxonomy, the per-supplier AP ledger schema and how it maps to each platform, the three operational frictions (demand-reference-to-invoice-number construction, service-period parse, and multi-managing-agent format variance), the VAT decision flow per line, the RICS 2nd Edition timing implications during the 2026 transition year, the five-route extraction-option comparison, the BACS file build, and the audit trail that keeps the whole intake defensible six years later.

Document taxonomy: what a UK multi-site tenant receives and what each document is for

A landlord-side document is not a supplier invoice. The five document types a multi-site tenant absorbs each carry different fields, behave differently against the lease, and post differently to the AP ledger. The distinctions matter at intake, not at year-end.

Rent demand. Quarterly or monthly, depending on the lease. References the lease clause requiring payment, the property, and the period. Under English law rent is payable per the lease whether or not a demand has been issued; the demand notifies the tenant, it does not create the obligation. The fields the AP record needs are the lease reference, the property reference, the period, the gross amount, and the bank details for the payment. Whether the line is VAT-bearing depends on whether the landlord has opted to tax the property, which is a supplier-setup question rather than a line-text question.

Service charge demand on account. An interim demand against the year's service charge budget, usually quarterly. Per the RICS Service Charges in Commercial Property 2nd Edition, the budget should have been notified to the tenant at least one month before the service charge year began, with cost-heading categories that reconcile to the year-end certificate. The on-account demand draws against that budget. The AP record needs the period, the cost-heading split where the managing agent provides it, and the budget basis against which the demand was struck, because the year-end check is certificate-against-budget.

Insurance rent demand. The landlord recovers the building insurance cost from the tenant. Insurance rent is exempt from VAT, falling under HMRC VAT Notice 701/36 on insurance. (Some practitioner sources reference 701/57 here; 701/57 covers health professionals and is the wrong notice for this purpose.) The tenant cannot recover input VAT on insurance rent, so the AP record needs an exempt_insurance flag distinct from the general exempt treatment used for non-opted rent. When you extract insurance rent demand UK commercial tenant data into the ledger, the line should land with its own VAT treatment code so the VAT return composition stays accurate downstream. Insurance rent is often issued separately by the managing agent or combined with the service charge demand on a single cover document.

Periodic service charge statement. An interim cost-tracking statement during the service charge year. Not every managing agent sends these; some send only the year-start budget and the year-end certificate. Where they do arrive, the statement is informational rather than payable. The AP record captures it as a non-payable reference document so budget-vs-actual visibility lives in the AP system alongside the demands it relates to.

Credit note. A refund against historic over-recovery or budget surplus. Treated in tenant AP as an offset against future demands from the same managing agent rather than as a standalone payable. The AP record holds it against the supplier with the original demand reference it relates to, and the BACS file build for the next payment run nets it against the gross demand total.

Two adjacent document types fall outside the in-year intake the article covers. The year-end RICS-compliant signed certificate is a different document, addressed to a different searcher (the property accountant doing year-end analysis), and is treated in the year-end RICS-compliant service charge reconciliation against the certified statement. The construction Application for Payment, served under the Construction Act 1996 in JCT and NEC contracts, is a different industry context and sits with the JCT and NEC application for payment versus VAT invoice distinction in UK construction.

The canonical layout across the five demand-type documents is consistent enough to plan against. The header carries the landlord, the managing agent, the property, the lease reference, the demand reference, the document date, the due date, and the period. The body carries the line items, with descriptions that frequently embed the service period dates inside the prose rather than in a structured field. The totals carry gross, VAT, and net. The footer carries the payment instructions, including the sort code, account number, account name, and the bank reference the managing agent expects the tenant to use. Where that layout shifts supplier-by-supplier, the workaround is the multi-managing-agent variance handling covered later in the article rather than a different schema.

The per-supplier AP ledger schema and how it maps to Xero, QuickBooks, Sage, NetSuite, and Dynamics 365 Business Central

The schema below sits between the demand pack and the AP system. It is system-agnostic in shape, rendered into whichever import CSV the tenant's AP system expects at the end of the run.

The canonical column set:

• supplier — the managing agent or landlord, as set up in the AP system.
• property_reference — the tenant's internal property or site code.
• lease_reference — the lease identifier the property accountant holds in the lease register.
• document_type — one of rent_demand, service_charge_demand, insurance_rent_demand, periodic_statement, or credit_note.
• demand_reference — the original reference the managing agent issued.
• document_date — the date on the demand.
• due_date — the date the demand is payable.
• period_from and period_to — the start and end of the service period the demand covers, in YYYY-MM-DD form.
• gross, vat_amount, vat_treatment, and net — the financial split, with vat_treatment taking one of standard, exempt, option_to_tax_property, exempt_insurance, or mixed_line_level.
• bank_sort_code, bank_account_number, bank_account_name, and bank_reference — the payment instructions for the BACS file.
• nominal_code — the posting nominal for the AP system's general ledger.
• posting_date — the date the AP record posts to the GL.

Each field earns its column. The document_type value drives default VAT treatment and the year-end reconciliation queue. period_from and period_to drive per-period budget-vs-actual aggregation. The bank fields feed the BACS file build directly without a second extraction pass. vat_treatment at line level rather than header level keeps the VAT return composition accurate when a single demand bundles opted-rent and exempt-insurance lines.

The system-by-system mapping picks up the same data into platform-specific field names. The differences worth knowing:

Xero. The InvoiceNumber field must be unique per supplier. This is the field the demand reference lands in, and the uniqueness constraint is what forces the construction rule covered in the next section. Supplier contact details carry the bank fields, line-level VAT lives on the bill line, account codes take the nominal, and the due date sits on the bill header. The Xero unique invoice number landlord demand UK tenant constraint is the single tightest rule across the major UK platforms, so a tenant running Xero alongside any other AP system can design the synthesised reference to satisfy Xero and let the other systems accept it as a longer-than-they-needed string.

QuickBooks Online. The RefNumber field accepts the demand reference and technically tolerates duplicates across periods, but team policy usually still requires uniqueness for audit traceability. Bills carry line-level VAT, and class can take the property tag where the chart of accounts is structured that way.

Sage 50. The supplier reference and the invoice reference are separate fields. This lets the demand reference go in one and the lease or property reference go in the other, which removes the need to overload either field. Nominal codes map cleanly to the posting nominal column.

Sage Intacct. Dimension-based posting suits multi-site portfolios. Location, department, and project dimensions absorb the property and lease references natively, which means the AP record's analytical depth lives in the dimensions rather than in concatenated text fields.

NetSuite. The vendor bill tranId plus otherRefNum arrangement lets the demand reference and a synthesised internal number coexist. Subsidiary, location, and class take the property dimensions; line-level tax codes carry the VAT treatment.

Dynamics 365 Business Central. Vendor Invoice No. sits separately from the internal document number, mirroring Sage 50's split. Dimensions hold the property and lease references. The posting date and document date are independent fields, which matters when the demand arrives late and the AP team backdates the document date but posts to current period.

Two practical implications follow from running these systems together in one multi-site tenant. First, the demand-reference-to-invoice-number synthesis has to satisfy whichever system has the tightest uniqueness rule the tenant has live (often Xero), so the construction logic targets the tightest constraint and the looser systems accept the result without modification. Second, the property and lease references belong in dedicated fields or dimensions, not in the description column. Year-end RICS certificate reconciliation depends on per-property aggregation, and a description-text-only property reference cannot be aggregated cleanly.

The schema lives upstream of the AP system, not inside it. The per-supplier ledger is the source of truth at intake; the AP system receives a rendered import CSV in its own field shape, and the source ledger keeps the audit trail back to the original demand PDFs.

Constructing a unique invoice number from a managing agent's demand reference

Managing agents number their demands for their own systems, not for the tenant's AP rules. A reference such as SC2026Q2-LO-87421 may be reused across periods; a single cover reference often bundles dozens of separate properties' lines under one number; some agents reset their internal sequence each financial year. Xero's per-supplier InvoiceNumber uniqueness rule then rejects the second arrival, or, worse, a tired typist posts the duplicate under a slightly different supplier name and the audit trail breaks silently.

Mapping demand reference to invoice number UK tenant AP requires a construction rule the tenant owns, not one inherited from the managing agent. The rule the article proposes: concatenate the managing-agent code, the demand date in YYYYMMDD form, and the property code, separated by hyphens, with an optional document-type suffix where the AP system surfaces several document types per supplier. For a CBRE service charge demand dated 25 March 2026 against property reference LON087, the synthesised number is CBRE-20260325-LON087-SCD. The shape survives across managing agents, properties, and periods, and stays inside the field-length limits Xero and the other major platforms impose.

Validation runs before posting. The synthesised reference is checked against existing AP records for the same supplier to confirm non-collision. Where the same managing agent re-issues a demand under the same date and property (a re-billed cancellation, a corrected line, a duplicate sent in error), append a sequence suffix: -R01 for the first re-bill, -R02 for the second. The supplier then sees a single AP record per posting event, the original demand and its re-bill both have synthesised numbers that survive Xero's uniqueness rule, and the audit trail captures both events.

Audit trail discipline carries the rest. The original demand reference stays captured in a dedicated original_demand_reference field on the AP record so it can be searched, matched against the managing agent's later remittance applications, and pulled into the BACS payment reference for the recipient's statement. The source PDF filename, the page within the file, and the line position within the page get captured against the extracted line, so a six-year-later HMRC look-back can recover the source document from the AP record alone without trawling a shared drive.

The multi-property bundle is the case the construction rule was designed for. A single cover demand covering forty properties resolves into forty separate AP records, each carrying a synthesised invoice number derived from its own property code, and each carrying the same original demand reference for cross-reference. The supplier ledger then shows forty rows for the quarter, one per property, and the year-end RICS certificate reconciliation can roll up against each property cleanly. A single AP record carrying a forty-line description column cannot be reconciled per-property without painful unpacking.

What the tenant gives up in exchange is internal. The synthesised number is not what the managing agent uses. That is the point: the managing agent receives payment with a reference that is recognisable to them in the BACS file (covered in the BACS section later), while the AP system carries the synthesised number that lets the tenant's own controls and year-end reconciliation work. The two references serve different parties and there is no reason for them to match.

Parsing the service period from a demand line description

The service period is almost never in a structured field. It is in the line text. A representative line on a service charge demand reads: "Service charge demand on account for the quarter 25 March 2026 to 24 June 2026 — Schedule 1 (Common Parts)." The AP record needs period_from as 2026-03-25 and period_to as 2026-06-24, not the whole string in the description column.

Capturing service period dates from landlord demand line description text matters for two downstream reasons. Year-end reconciliation against the RICS-compliant certificate aggregates costs by period; the apportionment matrix the 2nd Edition expects in the year-end certificate from 31 December 2026 onwards expects per-period costs to roll up cleanly. Both break if the period lives in a description string rather than in structured date columns.

Many older commercial leases still run on the English quarter days: Lady Day on 25 March, Midsummer on 24 June, Michaelmas on 29 September, and Christmas on 25 December. A demand referencing "the quarter to Midsummer 2026" resolves to a period ending 24 June 2026. A demand for "the Michaelmas quarter 2026" runs from 29 September 2026 to 24 December 2026, the day before the Christmas quarter day. The parse rule needs to read either a numeric date or a quarter day name and produce the structured date either way.

Newer leases have drifted. Calendar-quarter periods (1 January to 31 March, 1 April to 30 June, 1 July to 30 September, 1 October to 31 December) are common on retail and leisure leases struck in the last fifteen years. Month-anniversary patterns, where the rent date aligns to the lease commencement date, are common on individual property leases outside portfolio deals. The parse rule handles both: read the date format the demand line uses, return the structured period.

The instruction shape, where an extraction prompt is used, is concrete. Ask for the start and end date of the service period to be returned in YYYY-MM-DD form. Specify a fallback: if the line text contains a single date and a duration phrase (quarterly, monthly, half-year), derive the corresponding period; if the line text contains two dates, use them; if no period is recoverable from the line text, return the demand's document date as period_from and leave period_to blank for finance-team review rather than guess.

Ambiguous lines need flagging rather than resolution. A line reading "service charge — quarter 2 2026" carries no start or end date and no quarter day name; it relies on the lease's service charge year, which the property accountant holds in the lease register, not the AP clerk. The right move is to flag the line for review and let the property accountant apply the lease's year basis when the demand crosses their desk. Auto-resolving by assumption breaks the year-end reconciliation cleanly enough that the cost of asking is lower than the cost of guessing.

Getting period_from and period_to right at intake is the single biggest reduction in year-end reconciliation work. The year-end apportionment matrix expects per-period budgeted figures to roll up against actuals; if the intake period is wrong, the matrix builds against the wrong cells, and the reconciliation has to walk the demand pack again to fix it. Two minutes per demand at intake is worth two hours per property at year-end.

Multi-managing-agent format variance across CBRE, JLL, Savills, Knight Frank, Colliers and the long tail

A 240-site retail or leisure tenant rarely deals with one managing agent. The estate is typically spread across the five largest UK practices (CBRE, JLL, Savills, Knight Frank, Colliers), several mid-tier practices (BNP Paribas Real Estate, Cushman & Wakefield, Avison Young, Lambert Smith Hampton, Allsop), and a tail of regional and smaller agents holding specific properties. Each issues demands the tenant's AP function has to absorb. Naming them is descriptive of who the tenant deals with, not an endorsement of any one practice over another.

The CBRE JLL Savills service charge demand parsing UK tenant problem is the format variance between them. Each managing agent runs its own document template, its own demand-numbering convention, and its own PDF generation tool. Some send portal-generated PDFs with a consistent layout per managing agent, where every demand from that agent looks the same and a template-based parser handles them reliably. Some send emailed XLSX exports straight from their property management system. Some send PDF/A scans of office printouts that came off a managing agent's local printer.

The RICS Service Charges in Commercial Property 2nd Edition mandates content not format. The framework specifies what a year-end certificate must contain, when budgets must be notified, and how cost categories must be presented; it does not standardise the in-year demand template. Format variance persists by design. The framework is moving the content quality up; it is not moving the document layouts together.

Two approaches survive the variance for tenant-side extraction. The first is to classify the managing agent at the start of extraction, using a header or footer heuristic (the managing agent's name and logo are usually consistent on every demand they issue), and apply a per-managing-agent field-mapping refinement. This is the template-library approach: build a library of layouts for the agents the tenant deals with regularly, and accept that adding a new agent means adding a new template. The second is to use a prompt-based extraction that adapts to varied layouts rather than depending on a learned template. The prompt-based route is covered as one of the five extraction-option routes later in the article.

Honesty about the long tail matters. Roughly five percent of demands will arrive in a layout that lands outside the trained template library: a regional managing agent's PDF the tenant has not seen before, a one-off format the landlord has used directly without going through the managing agent, or a scanned document from an older system that does not OCR cleanly. The right move on that five percent is manual review, not a silent miscapture that pollutes the supplier ledger. Build the workflow expectation that some fraction always falls back to human eyes. A workflow designed for one hundred percent automation cannot recover from the cases that need attention, because nothing in it is built to surface them.

The cross-managing-agent point is that the per-supplier ledger schema absorbs the variance once intake is complete. The Xero or NetSuite ledger does not need to know whether a demand came from CBRE, JLL, or a regional surveyor in Manchester; the schema fields are the same. Variance lives at the extraction step; the schema normalises it. The downstream AP processes (approval workflow, BACS file build, year-end reconciliation, SAO audit trail) all operate on the normalised data and never touch the original format.

VAT classification per line: opted property, non-opted property, insurance rent, and the option-to-tax verification

Every line on a landlord demand needs one of five VAT treatments captured into the AP record:

• standard — rent on a property the landlord has opted to tax, charged at 20%.
• exempt — rent on a non-opted property, no VAT line.
• option_to_tax_property — service charge that follows the rent's option-to-tax election on the same property, charged at 20%.
• exempt_insurance — insurance rent, exempt under the insurance notice rather than under the general land-and-property exemption.
• mixed_line_level — a single demand bundling lines that fall into more than one treatment.

The option-to-tax rule is the load-bearing one for rent and service charge classification, and it lives in HMRC's primary guidance rather than in any practitioner summary. According to HMRC's option to tax guidance in VAT Notice 742A, for an option to tax on land or buildings to be valid, the authorised signatory must normally notify HMRC of the decision within 30 days. Once the option takes effect, supplies the landlord makes of that interest in the land or buildings (including rent and service charges on the property) become standard-rated. That single rule resolves most of the classification flow: if the landlord has opted to tax the property, rent and service charges on that property are standard-rated; if not, they are exempt.

Insurance rent falls outside the option-to-tax mechanism. It sits under HMRC VAT Notice 701/36 on insurance, which exempts insurance supplies. The practical consequence is that the tenant cannot recover input VAT on insurance rent, even where the property itself is opted. The AP record should carry the exempt_insurance treatment as its own value, distinct from the general exempt code used for non-opted rent, because the VAT return composition at the year-end aggregates the two differently and a partial-exemption tenant needs to keep the categories apart for the de minimis calculation.

The service-charge-follows-rent default does most of the day-to-day work. Where the landlord has opted to tax the property, the option covers the service charge supplied by the same landlord on the same property, so the service charge on that property is standard-rated alongside the rent. HMRC's Concession 3.18 covers an exceptional case for landlords supplying common-area services to a mix of opted and non-opted tenants, where the concession allows a different treatment. The call belongs at the finance-team level for the cases it applies to; flag the line for review rather than resolve it at intake.

Verification runs from the tenant's own supplier setup rather than from the demand line text. The opted-or-not status of each property is a fact the tenant holds on file, supported by the landlord's VAT 1614A confirmation. The supplier setup record carries the option-to-tax status; the demand line either agrees with it (a VAT line at 20% on an opted property is correct; no VAT line on a non-opted property is correct) or it disagrees and the line is flagged. A demand carrying a VAT line on a property the tenant's supplier setup records as not opted is the kind of borderline that justifies asking the landlord for the 1614A before posting.

What extraction can recover honestly: the line-level VAT amount, the line description, and a default classification based on the document type. Insurance rent demands default to exempt_insurance. Rent and service charge demands default to whichever treatment the supplier setup carries for the property in question. What extraction cannot determine in isolation is the option-to-tax verification on a borderline property; that posting decision belongs to the firm, made against its own VAT 1614A file, not against the demand text.

The mixed-line-level case is the reason for line-level VAT capture rather than header-level. Some demands bundle a rent line on an opted property (standard-rated) and an insurance rent line (exempt-insurance) on a single cover document. Some bundle a service charge line where most cost heads are recoverable and one cost head is not. Capturing VAT at line level keeps the VAT return composition accurate downstream and protects partial-exemption calculations from losing precision when a single header VAT figure has averaged across treatments.

RICS 2nd Edition timing and what changes for tenant AP during the transition year

The RICS Service Charges in Commercial Property 2nd Edition is effective from 31 December 2025, applies fully to service charge year-ends from 31 December 2026 onwards, and mandates accruals-basis accounting from April 2026. It replaces the 1st Edition as the operative professional standard for commercial service charges in the UK. The full RICS 2nd Edition service charge tenant AP impact lands at year-end rather than at in-year intake, but the in-year capture during the transition year is what makes the year-end check workable.

Four practical implications follow for the tenant AP function during the 2026 transition year.

Accruals basis from April 2026. In-year service charge demands during the transition year will carry hybrid budget bases. Some managing agents will move to accruals immediately and re-issue their year-start budgets on the new basis. Others will continue on cash basis through the transition year and switch at the next service charge year-end that crosses April 2026. The AP function does not arbitrate; it captures the demand at face value at intake and records which basis the year-start budget for that lease was struck on. The year-end certificate will then be checked against the budget basis that was actually in force, not against an assumption made at intake.

Apportionment matrix expected in year-end certificates from 31 December 2026 onwards. The 2nd Edition requires year-end certificates to include a detailed apportionment matrix showing how each cost head was allocated across the tenants in the building. The tenant-side AP intake should hold the per-period budgeted figures from the on-account demands, broken down by cost head where the managing agent provides the split, so the apportionment matrix at year-end can be checked line-by-line. Without the per-period breakdown captured at intake, the year-end reconciliation has to reconstruct the budget from the demand pack, which is the work the AP intake was supposed to make unnecessary.

Four-month commercial year-end certificate window. Year-end certificates are expected within four months of the service charge year-end under the 2nd Edition. That is a shorter window than the six months residential block managers operate under, so AP functions running multi-managing-agent estates should plan the year-end reconciliation queue to absorb certificates straggling through the four months rather than expecting them all on day one. The intake records from the in-year demands sit ready against each lease while the certificates arrive in batches.

Budget notification one month before the year start. The 2nd Edition expects budgets to be notified to tenants at least one month before the service charge year begins, with cost-heading categories that reconcile to the year-end certificate. The AP function captures and files the year-start budget against each lease so the in-year demands can be checked against the budgeted figures as they arrive. A demand for a cost head that does not appear in the year-start budget is flagged at intake rather than discovered at year-end.

Tenants holding mixed estates with both commercial and residential property work under two frameworks. The 2nd Edition covers the commercial properties; the residential service charges sit under the Landlord and Tenant Act 1985 and the residential RICS Service Charge Residential Management Code, which differ on tribunal jurisdiction, the 18-month rule under Section 20B, and the consultation regime under Section 20. The residential service charge year-end reconciliation under the Landlord and Tenant Act 1985 covers the residential analogue for tenants who need both.

The in-year AP intake feeds the year-end reconciliation. Capturing the per-period budget cleanly, the per-period demand cleanly, and the per-property apportionment cleanly at intake reduces the year-end reconciliation work to certificate-against-budget comparison rather than reconstruction from scratch. The year-end certificate analysis itself — the balancing-charge or balancing-credit calculation, the line-by-line check against the certified statement, the ICAEW TECH 09/14 BL accountant's-report component, and the dispute pathway where the certificate is challenged — sits with the year-end reconciliation companion article and is not re-covered here.

Five routes from demand PDF to AP-ready ledger

Five routes get a quarterly demand pack into an AP-ready ledger. None is universally right. The pick depends on portfolio size, format variance across managing agents, and the tenant's appetite for tooling investment.

Route 1: Manual typing into the AP system. Works for tenants under roughly ten sites. The per-quarter document count is low enough that a trained AP clerk can type each demand into Xero or QuickBooks Online without a structural problem, and the cost of building anything else outweighs the cost of the time. The route breaks at portfolio scale: once the quarterly demand count exceeds the AP team's headroom, fields start getting wrong, demand references collide, the BACS file goes out with stale bank details, and the supplier ledger drifts away from what is owed.

Route 2: Generic AP automation tuned for landlord documents. Coupa, Stampli, AvidXchange, Tipalti, Yooz, Klippa, Rossum, and Bill.com are invoice-shaped by default. They handle standard supplier invoices well — purchase orders, three-way matching, approval workflows — but they struggle with the demand-specific layouts, multi-line VAT, embedded service periods, and footer-position bank details that landlord demands carry. Several of these platforms can be tuned with custom fields and templates for landlord documents at moderate setup cost; the tuning effort is the cost the route carries, and the tuning has to be maintained as managing agents change their templates. A multi-site tenant running twenty-plus managing agents will tune for the top five or six and accept manual handling on the long tail.

Route 3: Lease accounting platforms. Sage Lease Accounting, MRI ProLease, LeaseAccelerator, and LeaseQuery are built for IFRS 16 lease liability and right-of-use asset capitalisation. They calculate the balance-sheet impact of the lease and produce the journals for the lease liability and the ROU asset amortisation. They do not handle operational AP intake. The lease accounting platform sits downstream of the AP system, working from approved lease data the AP function has already loaded; it is not a substitute for the demand-extraction step. A tenant with one of these platforms still needs a route to get the demands into the AP system first.

Route 4: Tenant-portal-based receipt. Some larger managing agents provide a tenant portal where the tenant downloads structured demand data directly, either as XLSX or via API. Re-Leased's landlord customers, MRI Yardi's landlord customers, and a few other platforms surface tenant-facing portals as part of the landlord's package. When available, this is the cleanest intake — the data arrives structured, the format is consistent, and the extraction step disappears. The catch is coverage: multi-site tenants almost always receive a meaningful share of documents from managing agents who do not offer a portal, so the route handles part of the estate and leaves the rest for another route.

Route 5: prompt-based extraction with the per-supplier schema. This is the route Invoice Data Extraction fits. The user uploads the quarterly demand pack — the CBRE PDFs, the JLL XLSX, the smaller managing agents' emailed files — into the workbench, writes a prompt that names the schema fields and the construction rules from the earlier sections, and downloads an Excel, CSV, or JSON file ready for AP system import. The same interaction pattern is what anyone who has used a modern AI tool already knows: a single prompt field with a file upload area, no templates to configure beforehand. The way to think about it is to extract data from UK landlord demand PDFs directly into a per-supplier AP ledger in one step rather than building an OCR pipeline plus a rules engine plus a post-processor.

The prompt shape that works for landlord demands is goal-oriented at the top and field-level at the bottom. The opening sentence states the task ("I am processing UK commercial landlord demands into AP — one row per demand line"). The middle states the schema fields ("Extract: Supplier (managing agent), Property Reference, Lease Reference, Document Type, Demand Reference, Document Date, Due Date, Period From, Period To, Gross, VAT Amount, VAT Treatment, Net, Sort Code, Account Number, Account Name, Bank Reference, Nominal Code"). The end carries the construction rules ("For Demand Reference, synthesise a unique identifier as managing-agent code + demand date in YYYYMMDD + property code, separated by hyphens. For Period From and Period To, parse from the line description in YYYY-MM-DD form. For VAT Treatment, classify as standard, exempt, option_to_tax_property, exempt_insurance, or mixed_line_level based on document type"). The same prompt produces the same structured output across the whole pack, which is what separates a purpose-built batch extraction tool from a general-purpose AI assistant — the latter handles a handful of invoices in a conversation but cannot hold consistency across hundreds or thousands of documents in a single job, and consistency is what makes a multi-site tenant's quarterly intake workable.

Saved prompts in the library matter at the multi-site tenant scale. The same demand pack arrives quarterly, with the same schema, against the same managing agents. The prompt library lets the AP function save the working extraction prompt once and apply it next quarter without re-writing. The output is delivered as Excel, CSV, or JSON, with each row carrying a reference back to the source file and page so the audit trail covered later sits ready without a second pass. For the broader-audience analogue — single-property landlord-side billing rather than the multi-site tenant-side AP intake — see generic rent invoice extraction for single-property landlord billing.

Honesty about what the route does and does not do. Extraction recovers the line-level VAT amount and a default VAT treatment based on document type, exactly as covered earlier; the option-to-tax verification on a borderline property remains a posting decision the firm makes against its own supplier setup and VAT 1614A file, not a determination the extraction makes in isolation. The five-percent long tail of format variance still needs human review.

Most multi-site tenants run a hybrid in practice: tenant portal where the managing agent offers one, prompt-based extraction or tuned AP automation for the bulk of the demands, manual handling for the long tail. The article does not pretend the workflow collapses to a single route. It does say that the per-supplier schema upstream of whichever combination of routes the tenant runs is what makes the hybrid hold together.

BACS bank-detail extraction and the payment-run file build

Once the per-supplier ledger is approved in the AP system, the next step is the payment-run file build. Typically a BACS 18-character standard file built to the BACSTEL-IP standard, with sort code, account number, account name, amount, and payment reference per line. The bank ingests the BACS file; the AP system holds the ledger record. Pulling BACS bank details from landlord demand UK tenant documents into that file cleanly is what closes the loop from arrival to payment.

The bank fields live in inconsistent places on the demand. Usually in the footer of the demand itself. Sometimes on a separate "Remittance Instructions" page bound into the PDF. Occasionally only on the first demand of a new lease, on the assumption that subsequent demands will reference supplier setup the tenant already holds. The extraction picks them up from wherever they appear; the AP record captures them once, supplier setup holds them across subsequent demands, and the BACS file build pulls from supplier setup at payment-run time.

The sort-code-on-first-demand-only pattern is common enough to plan against. Many managing agents provide sort code and account number on the initial demand for a new lease, then omit them from quarterly demands thereafter. The right discipline: capture on first arrival, hold in supplier setup, validate any subsequent demand that does carry bank details against what supplier setup already records, and flag if the captured details disagree with the supplier setup record. Silent overwrite is the wrong default; the conflict needs a human to confirm whether the managing agent has changed bank details or whether one of the demands is wrong.

The changed-bank-details case follows the same principle but resolves the other way. A managing agent has genuinely changed bank, and the new demand carries the new sort code and account number. The demand is the authoritative new instruction. Supplier setup updates to the new details, the BACS file uses the new details for that payment run, and a payment-instructions-changed audit note attaches to the supplier record carrying the timestamp and the source demand reference. A later query — internal audit, HMRC enquiry, dispute with the managing agent — can recover the change from the supplier record without ambiguity about when the switch happened or which demand authorised it.

The BACS payment reference is what the recipient sees on their statement. Composing it from the original demand reference plus the property code lets the managing agent apply the receipt cleanly. Where the synthesised internal invoice number from earlier is CBRE-20260325-LON087-SCD, the BACS payment reference is more useful to the recipient as SC2026Q2-LO-87421-LON087 — the managing agent's own reference plus the property code. The AP system's internal invoice number and the BACS payment reference serve different parties and there is no reason for them to match.

UK domestic leases are almost always GBP and route through BACS. Tenants of internationally-owned portfolios occasionally see USD- or EUR-denominated rent on prime central London assets where the landlord operates in another currency. The AP record holds the currency code and the FX rate basis used at posting. The payment file build switches accordingly: SEPA for EUR-denominated payments to recipients in the SEPA area, SWIFT for USD or for EUR payments outside SEPA reach. The BACS file is GBP-only, so multi-currency volume tends to route through a parallel international payments process at the tenant's bank.

One administrative note for tenants new to BACS submission: the BACS Service User Number (SUN) is what authorises the submission. The tenant's bank issues the SUN, and the BACS submission carries it as part of the header. It is a one-time setup at the tenant side rather than a per-demand field, but a tenant moving from Faster Payments to BACS for quarterly rent runs needs the SUN in place before the first scheduled run.

Audit trail, six-year retention, and SAO alignment for large multi-site groups

Every captured field on the per-supplier ledger should carry a source-file reference: the filename of the original demand PDF, the page within the file, and the line position within the page. This makes the AP record its own audit document. A six-year-later HMRC enquiry can recover the source demand from the AP record alone, without trawling a shared drive looking for which file the line came from. The discipline costs three extra columns at intake and saves days of work whenever the records get tested.

HMRC retention windows pin the storage policy. VAT records must be kept for six years; corporation tax records must be kept for six years from the end of the accounting period to which they relate. For landlord-side documents, the tenant's AP retention policy aligns to the longer of the two, because the same demand evidences both the input VAT recovery position (where applicable) and the deductible expense for corporation tax. Holding the source PDFs for six years from the end of the relevant accounting period covers both.

The Senior Accounting Officer regime applies to large multi-site groups. Broadly, the regime catches groups with UK turnover above £200 million or balance sheet total above £2 billion, measured on the qualifying-companies basis introduced by Schedule 46 of the Finance Act 2009. The SAO must certify that the company's tax accounting arrangements are appropriate to enable accurate tax returns. A defensible AP intake — source-file reference per field, synthesised invoice numbers that map back to the original demand reference, line-level VAT capture rather than header-level, the audit note on bank-detail changes — is exactly the kind of arrangement the SAO certification depends on. The SAO does not sign off process by description; the certification rests on records that can be tested.

The RICS 2nd Edition reinforces the same discipline from the other side of the lease. The framework expects the tenant's right to audit the service charge calculation to be supported by the documentation the landlord holds. The tenant's mirror obligation is to hold its own intake records cleanly enough to make use of that right when needed — to compare the year-end certificate against the demands the tenant actually received, against the bank details the tenant actually paid, and against the period allocations the tenant captured at intake.

The practical hold-and-store policy combines two windows. Keep the source PDFs of demands and statements for the longer of the six-year HMRC window and the lease term plus a year, because lease disputes can reach back across the term of the lease to demand-period evidence. The extracted ledger lives in the AP system on a separate retention cycle; the source PDFs live in the document store, with the AP record carrying the filename, page, and line-position reference that lets either record reconstruct the other.

The intake described across this article is the same whether the tenant runs twenty sites or five hundred. What changes at scale is the audit trail discipline. Document taxonomy, the per-supplier schema, the demand-reference synthesis, the service-period parse, multi-managing-agent variance handling, the VAT decision flow, the RICS 2nd Edition transition-year capture, the five-route extraction-option pick, and the BACS file build all work the same at either size. The audit trail is what makes the year-end reconciliation cheap, the SAO certification defensible, and any HMRC enquiry survivable from the AP record alone.