Arthur Online: Supplier Invoices to Xero Tracking Categories

An ad-hoc supplier invoice that didn't come through FixFlo or the Arthur Online work-order module — the annual gas-safety CP12 emailed by the engineer, an EICR PDF from the electrician, the insurance broker's renewal statement — has to be posted into Xero by hand against two tracking categories: Tracking Code 1 (Unit) and Tracking Code 2 (Property). Xero allows two tracking categories per organisation, and Arthur Online's convention for supplier invoice Xero tracking categories names them Unit and Property so that the Profit & Loss by Tracking Category 2 returns the per-property P&L at year end. Each bill line carries its own tracking selections, so a multi-property invoice — insurance covering several buildings, a contractor charging across two flats — is split into one CSV or bill line per property with its own tracking option.

Bills raised inside Arthur — reactive maintenance dispatched through FixFlo, planned tasks through the work-order module, contractor invoices uploaded back into those work orders — sync to Xero with both tracking categories pre-populated. The CP12 that landed in your inbox an hour ago, the locksmith's photo of a paper receipt, the lift-insurance renewal forwarded by the property manager — none of those came through the platform, and none of them carry a property tag. Posting them with the right Tracking 1 and Tracking 2 against the canonical Xero option strings is the workflow this guide walks.

Three approaches sustain that workflow at different portfolio sizes. Direct entry in Xero with the dropdowns holds up to about thirty properties; supplier-rule data capture through Hubdoc, Dext or AutoEntry gets you to roughly a hundred and fifty; pre-Xero AI extraction with property matching and a Xero-import CSV scales beyond two hundred and works for the bookkeeper running several property-management clients off one desk. Each route gets its own section, with the property-identification step, the tracking-option-name discipline, and the failure mode that breaks it.

The Tracking Category Convention: Unit on One Axis, Property on the Other

Arthur Online's working convention names Tracking Category 1 as Unit and Tracking Category 2 as Property. The Unit axis is the lettable thing — the flat, the room in an HMO, the individual leasehold unit, the single desk in a serviced workspace. The Property axis is the building or block those units sit inside. Some firms reverse the order, putting Property on Tracking 1 and Unit on Tracking 2, and that works as long as the convention is consistent across every bill, every supplier rule, every CSV import, and every report. The dependency to remember is that Xero's per-property report is named after the axis it uses: Profit & Loss by Tracking Category 2 reads the second category, so whichever axis carries the property has to be the one named in that report.

Xero caps every organisation at two tracking categories. That cap is the reason the convention has to be deliberate: if the practice also wants per-tenancy reporting, per-room reporting in HMOs, or a portfolio-segment cut above the building level, those dimensions cannot also live as tracking categories. The usual fixes are description suffixes on bill lines, a separate Xero organisation per portfolio, or external reporting that pivots on the Xero export — none of them as native as the two-category report, and that is the working trade-off. Name the property cut you most need at year end, and use the second category for it.

The chart of accounts works alongside the tracking categories rather than carrying any of the property dimension itself. Accounts hold the cost type — rent income, repairs and maintenance, insurance, agent fees, ground rent, service charge, mortgage interest. Tracking 1 holds which unit, Tracking 2 holds which building. A single insurance bill posted against the insurance account with Tracking 2 set to Acacia Avenue and Tracking 1 left blank is a building-level cost on the property; an internal-decoration invoice on the same property posted against repairs and maintenance with Tracking 1 set to Flat 3 is a unit-level cost on a specific flat. Same chart of accounts, different tracking, different P&L row.

That makes tracking-option naming the one piece of setup discipline that pays off everywhere downstream. Every property in the portfolio needs an option on the Property category, and every lettable unit needs one on the Unit category, with one canonical form per property and per unit. Pick a casing convention — title case for road names like Acacia Avenue, the unit identifier as it appears on the tenancy like Flat 3 — and use it nowhere else in any other casing. Strip trailing whitespace at creation; that is the silent break in CSV imports and capture-tool rules. A property that the practice has historically called both 12 Acacia Avenue and Acacia Avenue needs one option, not two, and any bill posted against the wrong one has to be re-tagged before year end.

The FixFlo Happy Path and the Ad-Hoc Gap That Lands in the Inbox

The platform-handled flow is worth describing precisely, because once you can name what FixFlo does, you can stop treating those bills as your problem. A tenant raises a maintenance issue in Arthur's tenant portal. Arthur dispatches it through FixFlo. FixFlo routes the job to the right contractor on the panel, the contractor completes the work and uploads their invoice into FixFlo against the work order, FixFlo posts the bill back into Arthur with the property and unit tags already attached, and Arthur's Xero sync writes it across with Tracking 1 and Tracking 2 set on every line. That's the rail. Reactive maintenance through FixFlo, planned tasks through Arthur's work-order module, contractor invoices uploaded back to those work orders — all on the rail and all out of scope for hand-posting.

The limit is exactly there. Anything that did not originate in Arthur, did not pass through FixFlo, and was not attached to an Arthur work order does not arrive in Xero with tracking. The bills that don't ride the rail are the ones the bookkeeper has on their desk: the annual gas-safety CP12 emailed by the engineer, the boiler service invoice from the heating contractor on the framework agreement, the EICR PDF from the electrician, insurance renewal statements from the broker, the EPC assessor's invoice, the licensed window cleaner who attaches a PDF every quarter, the lift-insurance broker for the block, the locksmith called out for an emergency lock change, the legionella risk assessment from the consultancy, the fire-alarm service from the engineer who never logs into FixFlo. Each one has a property name (sometimes only in the email subject line), a supplier, an amount, and no platform tagging.

The lookup step that vendor docs skip is what every ad-hoc invoice forces you to do. Read the property address from the PDF, which might be in the header, the footer, the description body, or only in the email body the PDF was attached to. Match it to the canonical Property option in Xero — the same string you set up under the convention in the previous section. If the cost is unit-level, match the Unit option as well. Enter the bill with both tracking selections set on each line, or import a CSV that already has them set, or have a capture tool set them via supplier rule. The three routes that follow differ entirely in how that lookup happens at scale.

The cohort doing this work at scale is large. Propertymark's data on ARLA member coverage of England's private rented sector reports that ARLA Propertymark members manage roughly 47 per cent of England's private rented sector across more than 10,000 letting agency branches. Most of those firms run a property-management front-end on top of Xero, most of them route platform-originated bills through their integration, and most of them hand-post the ad-hoc inbox stream against the same tracking-category convention. The friction this article describes is what every one of those bookkeepers is solving for, often inside the property-management vendor invoice tracker workflow that sits behind the per-property routing.

Route 1: Direct Entry in Xero with Manual Tracking Selection

The simplest sustainable workflow is also the one most boutique practices already run. Open the supplier PDF, read the property reference off it, open Xero, create the bill against the supplier contact, type the line description, set the account and tax type, then set Tracking 1 (Unit) and Tracking 2 (Property) from the dropdowns on each line. Save. The whole procedure is the bill-entry workflow in Xero with two extra dropdown selections per line. Direct entry is one of six methods for converting PDF invoices to Xero compared at the generic level; what makes it Route 1 here is the tracking-selection discipline applied on every line.

A portfolio of around thirty properties typically generates somewhere between thirty and eighty ad-hoc supplier invoices a month once you count compliance certificates, insurance renewals, recurring maintenance contracts, and the one-off jobs that come up. At a couple of minutes each — open the PDF, find the property, set the bill, set the tracking — that is an hour or two of focused work a month. Sustainable, and at thirty properties most practices keep doing it because the volume doesn't justify rule maintenance or batch tooling.

The failure mode that vendor documentation skips is the one that breaks year-end. Xero's tracking-option dropdown lists every option on the category, and once a portfolio has near-collisions in the option strings — Acacia Avenue, Acacia Avenue (Flat 3), Acacia Court, Acacia Road — the wrong selection still posts a clean bill. Xero accepts the entry, the cost lands against a real property, just not the right one. There is no error to chase, no rejection email, nothing in the audit trail to flag a misposted line. The only signal is the year-end Profit & Loss by Tracking Category 2 showing a property's repair costs higher than the property manager remembers, and at that point the bookkeeper is reviewing twelve months of bills to find the misallocations.

Three mitigations make Route 1 robust within its ceiling. First, name tracking options to minimise near-collisions: include the road number or block name where addresses repeat in the area, prefer 12 Acacia Avenue over a bare Acacia Avenue if any other Acacia property is on the books, and never let two options differ by punctuation or casing alone. Second, run a Profit & Loss by Tracking Category 2 review monthly rather than annually — misallocations are far cheaper to fix in the same period they were posted, while the audit trail is fresh and the original PDFs are still on the bookkeeper's desk. Third, set a default tracking option on the supplier contact in Xero whenever a supplier reliably serves one property: the lift-insurance broker for the one block, the gardener for the one estate. The default still has to be confirmed on each bill, but it removes the dropdown lookup for the cases where the lookup is deterministic.

Route 2: Email-to-Bill with Hubdoc, Dext or AutoEntry Rules

Forward (or auto-forward) the supplier inbox into the capture tool's intake address. The tool reads each PDF, identifies the supplier, applies the rule you've configured for that supplier, and pushes a draft bill into Xero with the account, tax type, and tracking categories pre-set. The bookkeeper reviews the draft, confirms (or corrects) any line that needs a human eye, and approves. The mental model is straightforward: data capture's job is to read the PDF and apply rules, not to think about which property the invoice is for. The rule does the property thinking, on the supplier's behalf, every time. Hubdoc, Dext and AutoEntry compared for Xero data capture treats the choice between the three on its own; the substance for property tracking is the same across all three.

Where supplier rules earn their place is the deterministic case. A supplier who reliably serves one property — the lift-insurance broker on the one block, the gardener for the one estate, the cleaning contractor on the single HMO — gets a rule that pre-fills Tracking 1 and Tracking 2 to the right options every time. The bookkeeper approves drafts in batches without doing dropdown lookups. Where supplier rules give way is the multi-property case. The regional gas-safety contractor visiting sixty flats across twelve buildings cannot be pre-tagged at the supplier level, because the property dimension shifts on every invoice. The insurance broker covering twenty buildings on a single annual statement cannot either, because the bill itself spans properties. For those suppliers the rule sets the account and tax type, and the bookkeeper still selects Tracking 1 and Tracking 2 manually on draft.

The honest failure mode is rule-library maintenance. Each new property adds suppliers; each multi-property supplier needs new logic if the firm wants the tracking pre-filled where the line description gives it away; tracking-option names that drift after a property rename — 12 Acacia Avenue becoming Acacia Avenue after a tenancy reshuffle — silently break every rule that referenced the old option, and capture tools rarely raise an explicit error for that. They write the bill with no tracking, or with the rule's default, and the bill posts. The maintenance cost of the rule library scales faster than the property count, and the practice that grows past about a hundred properties on a single client typically discovers that rule reviews are taking longer than the manual entry they replaced.

The case-sensitivity discipline that breaks CSV imports below applies to capture-tool rules in exactly the same way, because rules and CSVs share the constraint. A rule that writes acacia avenue against a Xero option of Acacia Avenue does not match — the bill drafts without tracking, or with whatever default the rule names. Trailing whitespace fails the same way. The rule library has to mirror the canonical option strings exactly, and any property rename in Xero needs a corresponding rule sweep, or the gap shows up as untagged costs in the year-end report.

Route 2 fits the band roughly between thirty and a hundred and fifty properties, with the caveat that the practice has to be willing to maintain the rules. Beyond that, rule maintenance becomes the bottleneck the route is supposed to remove, and a different model makes more sense.

Route 3: Pre-Xero AI Extraction with Property Matching and CSV Import

Past about a hundred and fifty properties on a single client, or for the bookkeeper running several property-management clients off one Xero login, the workflow that holds is batch extraction before Xero rather than rule-based capture inside it. Collect a month's ad-hoc supplier invoices into a single batch — the email forwards, the scanned receipts, the broker's annual statement, everything in the inbox that didn't come through Arthur. Run the batch through a pre-Xero extraction step that pulls the supplier name, invoice number, dates, amounts, and the property identifier from each PDF, matches that identifier to the canonical Xero tracking-option string, and writes the result as a CSV in Xero's bill-import format with both tracking columns pre-populated. Review the CSV, import it into Xero in one upload. The bills draft with tracking already set; the bookkeeper approves the batch rather than each bill. Under this model, the workflow described is exactly what automated invoice data extraction with property matching for Xero produces — a Xero-import-ready CSV from a batch of inbox PDFs, with the property dimension matched against the practice's actual Xero tracking options before the file ever touches Xero.

Property matching is the hard part of this route, not the data extraction itself. Modern extraction handles the supplier name, invoice number, and amounts with the same accuracy whether the document is a clean PDF or a phone photo of a paper receipt. The challenge is that the property identifier on a real-world ad-hoc invoice can be anywhere — the address line of the bill, the description column on a single line, the project reference, the email subject the PDF was attached to, or simply the booking reference the contractor wrote in their notes. A working Route 3 has to match a free-text property reference to the canonical Xero option string with the same case-sensitivity discipline that Route 2 demands of supplier rules. The match runs once per invoice in the batch, against a property list maintained at the client level.

The workflow runs on a prompt-driven extraction step. The bookkeeper uploads the month's PDFs as a single batch and writes a prompt that names the supplier fields the Xero CSV needs — supplier contact, invoice number, invoice date, due date, description, net amount, tax type, account code — alongside the property list the matching step uses to write TrackingOption1 and TrackingOption2 against the canonical Xero strings. The output is a Xero-import-ready CSV; the bookkeeper reviews the file, adjusts any unmatched property reference, and imports.

The route-2 ceiling resolves because the maintained list shifts from supplier rules to property options. Each client maintains a property list rather than a rule library: adding a new property is a one-line addition, renaming a property is a one-line change, and the matching step does the lookup once per invoice rather than once per supplier rule. The bookkeeper carries one list per client instead of tens of supplier rules per client, and the practice scaling past one client at a time scales the list count rather than the rule count.

The multi-client bookkeeper case is where the difference becomes obvious. A practice servicing five property-management clients on Xero might be running anywhere between two hundred and fifty and six hundred properties combined; under Route 2 the rule-library cost multiplies by client, and so does the rule-review cost when property names drift. Under Route 3, the practice runs each client's monthly batch with the client's property list, outputs one CSV per client, imports each into the right Xero organisation, and approves the drafts. The model is the same per client; the volume is whatever the inbox holds. Where this fits in the wider category is covered separately in property-management invoice processing software compared by portfolio scale.

The Xero Bill Import CSV Format and Tracking-Option Discipline

Xero's CSV import format for purchase bills lays out the generic column structure; this section extends it for tracking-aware property bookkeeping. The columns Xero accepts on the bill-import endpoint, in order:

*ContactName | EmailAddress | *InvoiceNumber | *InvoiceDate | *DueDate | Description | *Quantity | *UnitAmount | AccountCode | *TaxType | TrackingName1 | TrackingOption1 | TrackingName2 | TrackingOption2 | Currency

The asterisked columns are mandatory in Xero's general format. The four tracking columns at the end are technically optional in that format but are mandatory in practice for property-management bookkeeping — leaving them blank is what produced the (None) catch-all that the year-end report flags. Treat them as required for every bill the practice imports.

The exact-match constraint is the gotcha that breaks bulk imports for property managers. TrackingName1 must match the tracking-category name in Xero exactly: Unit, not unit, not Units, not UNIT. TrackingOption1 must match the option exactly with full case-sensitivity: Flat 3, not flat 3, not Flat3, not Flat 3 with a trailing space. The same constraint applies to TrackingName2 against Property and to TrackingOption2 against the canonical property option string. A mismatch on any of those four columns silently strips the tracking from the line. Xero accepts the bill, the line posts without tracking, and the cost lands in the (None) column on the per-property P&L. There is no rejection email; the only signal is the report. This is why the canonical option strings established in setup have to be the only strings the practice ever uses across capture-tool rules, CSV exports from Route 3, and any historical-bill imports during onboarding.

A multi-property invoice — the insurance broker covering six buildings on one annual statement, the contractor billing across two flats on a single invoice — splits into one CSV row per property. Same ContactName, same InvoiceNumber, same InvoiceDate and DueDate, then one row per property with its own Description, UnitAmount, AccountCode (insurance, repairs and maintenance, whatever the cost type is), TrackingOption2 for the property, and TrackingOption1 for the unit if the cost is unit-level (or blank if it's at building level, as insurance usually is). Xero treats consecutive rows with the same InvoiceNumber as lines on a single bill, so the import lands as one document with however many tracked lines the original invoice spans. The bill total reconciles against the supplier's invoice total because each line carries its own apportionment.

Supplier credit notes need the tracking reversal handled deliberately. A credit note that reverses a previously posted bill must carry the same TrackingOption1 and TrackingOption2 as the bill it credits, line for line. A credit note posted with the wrong tracking — or no tracking — creates the worst kind of error in property bookkeeping, because the totals net out at the organisation level while the per-property P&L now shows the cost in one column and the credit in another. Reconciliation against the supplier statement does not catch this, and the property manager only spots it when the per-property P&L numbers stop matching the property's actual spend.

Bulk-import failure modes the bookkeeper actually hits beyond the four tracking columns: option names that drifted after a property rename and were not swept through the historical import file; suppliers used during the month whose contacts weren't yet in the contact list (Xero creates the contact on import, but the practice loses the supplier-default tracking on the new contact until it is set); decimal precision on UnitAmount when the source PDF rounded differently from the bookkeeper's spreadsheet; date format inconsistencies between regions on the same Xero organisation if the practice runs UK and ANZ entities together. The most common Xero CSV import errors and how to fix them catalogues the wider error set; this section covers the property-tracking subset because nothing in the generic catalogue addresses the silent-mismatch failure on the tracking columns.

Re-Leased, Property Tree and Hammock: Sibling Stacks with Their Own Conventions

Arthur Online is one of several front-ends a UK practice runs on top of Xero. Re-Leased sits at commercial property firms and at lettings practices with bigger leasehold portfolios; Property Tree shows up at UK offices that inherited the ANZ-origin platform from MRI; Hammock is what limited-company landlords often run before the year-end Xero export. Each has its own tracking convention, and the rest of this article applies once the convention shift is mapped.

Re-Leased typically uses tracking categories with Tracking 1 = Property and Tracking 2 = Building — the building cut sits above individual leasehold units in commercial portfolios where one leaseholder occupies one or several units inside the building. For simpler residential portfolios, Tracking 2 is often left empty and the practice runs a single-axis property cut on Tracking 1. The implication for the reader on Re-Leased: the route-1, route-2, and route-3 patterns hold without adjustment, the tracking-option content shifts to whatever the Re-Leased setup writes, and the per-property P&L runs from Tracking 1 rather than Tracking 2. Re-Leased's own Xero sync handles work-order-originated bills the same way Arthur's does; the ad-hoc gap is the same gap, just on a different axis.

Property Tree (MRI) is ANZ-origin and used at some UK offices that inherited it through acquisition or franchise relationships. UK Property Tree practices typically configure Tracking 2 as Property and use Tracking 1 for portfolio segmentation — by branch, by client portfolio, or by management-fee structure — rather than per-unit. The three-route ladder applies; the Profit & Loss by Tracking Category 2 still produces the per-property P&L; the option strings reflect whatever the Property Tree configuration writes through to Xero on the platform-handled bills.

Hammock is landlord-focused rather than agent-focused, and the workflow shape changes accordingly. Many Hammock users export to Xero only at year-end for the SA105 submission, rather than running daily Xero AP. For these landlords, the ad-hoc supplier invoice often skips Hammock entirely — the gas-engineer's CP12 lands in a personal email inbox, the EICR PDF goes into a folder on the desktop, and the year-end push pulls all of it into Xero in a single batch upload. That is Route 3 with a once-a-year tempo rather than a monthly one. The convention these landlords should adopt mirrors Arthur's: Tracking 1 = Unit (or empty for whole-house lets where there is only one let per property) and Tracking 2 = Property. The discipline is the same; the rhythm is annual.

What holds across all three sibling stacks is what holds for Arthur. Two tracking categories per organisation, case-sensitive option matching on rules and CSV imports, multi-property line splits on a single bill, credit notes that have to reverse against the original tracking. None of those depend on which front-end the practice runs. The route the practice picks depends on portfolio scale and how many clients the bookkeeper carries; the convention depends on the platform; the underlying mechanics belong to Xero.

The Year-End Output: Profit & Loss by Tracking Category 2

The reason for the discipline is one Xero report. Profit & Loss by Tracking Category, run with Tracking 2 (Property) as the dimension, returns one P&L column per property. Rent income, repairs and maintenance, insurance, agent fees, ground rent, mortgage interest, service charge — every cost type the chart of accounts holds, broken out building by building. That is the report the SA105 schedule pulls from for an individual landlord, the report the limited-company landlord's CT600 pulls from for corporation tax accounts, and the report the property manager hands the client at year end as evidence the per-property bookkeeping ran cleanly.

The first thing the bookkeeper checks on the report is the (None) column at the right-hand edge — Xero's catch-all for any cost that posted without a Tracking 2 selection. Anything sitting in (None) is a bill the practice missed: a Route 1 dropdown the bookkeeper left blank, a Route 2 supplier rule that mismatched the tracking option after a property rename, a Route 3 CSV row that wrote acacia avenue against an option string of Acacia Avenue and silently lost the tracking. The reconciliation step is to drill into each (None) line, find the bill in Xero's audit trail, identify which property it belonged to, and reallocate. The discipline of the (None) column being empty is what the year-end review is checking; everything in earlier sections existed to keep it that way.

From April 2026, the per-property P&L is also what bridging software submits to HMRC under how MTD for Income Tax reshapes per-property record-keeping from 2026 for individual landlords. The submission cycle becomes quarterly rather than annual, and the SA105 schedule that previously sat at the back end of self-assessment now feeds four quarterly updates plus a year-end finalisation. The dimensional data the bridging software needs is the per-property P&L from Tracking Category 2 — the same report this section names. Limited-company landlords feed equivalent dimensional data into corporation tax filings on the existing CT600 cycle, with no MTD ITSA timing change. Either way, the discipline this article walks is what makes the submission tractable; without it, the bookkeeper rebuilds the per-property cut on a spreadsheet at year end, and the MTD ITSA quarterly cycle makes that rebuild four times a year instead of once.

The routine reconciliations the year-end review covers beyond (None) sweep: prior-year comparatives by property, where a year-on-year jump on one property's repairs line usually points to either a real maintenance event or a posting that sat against the wrong property until reallocation; mid-year tracking-option renames that orphaned earlier bills, where a property renamed in month seven needs every prior bill swept to the new option string; and suspense or unallocated balances from journal corrections during the year.