Strata & Body Corporate AP: Multi-Scheme Supplier Invoices

At a strata or body corporate management firm, every supplier invoice has to land on four things at once: it must be allocated to one specific scheme, coded to that scheme's budget line, routed through the correct delegated-authority threshold (manager, committee, or AGM), and paid from that scheme's trust ledger. Allocating to the wrong scheme is a trust-account compliance issue rather than a coding error, which is what makes strata and body corporate manager supplier invoice AP structurally different from corporate AP and worth treating as its own problem.

Scale forces the issue. A mid-sized firm typically manages somewhere between 100 and 500 schemes and processes 5,000 to 15,000 supplier invoices a year — cleaners, gardeners, lift servicers, fire-safety inspectors, brokers, building managers, plumbers, electricians, painters, capital-works tradespeople, and the rest of the recurring mix. Every one of those invoices has to walk the same allocation, coding, approval, and trust-ledger path. Get it wrong on a handful of invoices in a small firm and corrections are absorbed; get it wrong systematically across hundreds of schemes and the trust-account auditor's findings become a regulatory matter.

This article is written from the firm's perspective — the strata management firm running AP at scale — not from the lot owner's. The lot-owner side is a different searcher with a different document and a different problem; readers working on that side should look at extracting NSW strata levy notices to a working spreadsheet and the corresponding state articles in that set rather than this one.

The walkthrough below covers four operational pillars: scheme allocation (single-scheme and multi-scheme broker patterns), GL coding to the scheme's AGM-approved budget, the manager-committee-AGM approval threshold matrix, and trust-account discipline as the constraint that shapes everything upstream. Running through those pillars are two cross-cutting decisions firms have to make: where each AU strata software product genuinely sits in the AP layer (extraction, classification, approval routing, trust-ledger integration), and which of three extraction routes — manual entry, in-platform OCR, or pre-platform AI — fits the firm's invoice volume.

The supplier mix and the GL coding library it forces

A typical residential scheme generates a recurring supplier mix that hardly varies from one strata firm to the next. Most schemes carry monthly invoices from a building manager or caretaker, a cleaning contractor, a gardening and landscaping contractor, and the common-area utilities — electricity, water, and gas. On top of that sits the periodic compliance mix: lift servicing from one of the major OEMs (Otis, Schindler, Kone, ThyssenKrupp Elevators), fire-safety inspection, smoke-alarm compliance, intercom and access-control servicing, garbage-chute servicing, pool maintenance, security patrol, common-area air-conditioning servicing, pest control, statutory roof-anchor inspection, and exit-signs and emergency-lighting testing. The annual layer adds the building insurance broker, gym equipment maintenance where there's a gym, and audit and tax-return work for the scheme. The ad-hoc layer covers plumbing and electrical repairs, periodic painters and carpenters, capital-works tradespeople, and professional services — engineers' reports, valuers, lawyers, and the auditor.

That mix is what shapes the chart of accounts. The GL coding library at any strata firm isn't a generic chart pulled out of an accounting textbook; it's a list of budget lines that mirrors the supplier mix above. Cleaning invoices code to Cleaning Common Property. Lift servicing codes to Lift Maintenance. The broker codes to Building Insurance. Fire-safety inspection and smoke-alarm work code to Fire Services or to a more granular split where the firm tracks them separately. Intercom and access-control work usually codes to Security or to a dedicated Access Control line on schemes that report it that way. Capital-works tradespeople code against the capital works fund line for the project rather than the routine maintenance line.

A useful distinction the supplier mix forces, and one the next section depends on, is between suppliers who invoice each scheme separately and suppliers who invoice across many schemes in a single document. The plumber, the electrician, and the gardener generally invoice per scheme — the work was done at one address, the invoice carries that scheme's reference, allocation is direct. The building insurance broker and the firm's own building-management arm tend to invoice across many schemes in a single statement, leaving the AP function to split one supplier document across many scheme ledgers.

The GL coding library is one of the firm's own assets — refined over years of processing real invoices, often with idiosyncratic lines for shared facilities, contributed lots, or unusual mixed-use scheme structures. The AP function maintains it. New supplier types drive new lines or new mappings, and the firm's coding library is what makes scheme-by-scheme budget reporting comparable in the first place.

Scheme allocation — single-scheme invoices and the multi-scheme broker pattern

Allocation is where the AP workflow earns or loses its trust-ledger integrity. Most invoices follow the single-scheme pattern: the supplier did the work at one address, and the invoice carries an identifier that ties it to one scheme — a BCN in Queensland, a strata plan number in New South Wales, an OC plan number in Victoria, or the scheme's trading name where the supplier knows the scheme by that. Allocation in this pattern reduces to two decisions: classify the scheme, then code the GL line. The plumber's invoice for an after-hours leak at a specific building is an unambiguous match to that building's scheme.

The multi-scheme broker pattern is where the workflow gets harder. Annual building-insurance renewals frequently arrive as a single statement from the broker covering many schemes' policies in one document, with each scheme's premium itemised on its own line. The firm's own building-management fee is typically billed across all schemes the firm manages, again in a single statement. Common-area utility consolidations occasionally span shared facilities where two adjacent schemes meter together. In every case the AP function has to split one supplier document across many scheme ledgers — not as a single consolidated entry, but as separate trust-ledger entries against each affected scheme.

Pro-rata allocation is the mechanic. Where the supplier itemises by scheme — most insurance brokers do, and most building-management fee schedules do — the per-scheme split is read from the invoice line items directly. Where the supplier consolidates without itemising, the firm has to apply its own split logic, usually against an allocation table that records each scheme's share of a shared facility or each scheme's contribution rate to a multi-scheme charge. Either way, the trust-ledger entries land scheme by scheme. A single consolidated entry against an arbitrary scheme is what creates trust-account compliance failures down the line. The same multi-entity discipline applies in other settings — for example, multi-campus supplier invoice allocation at Irish Technological Universities is a parallel problem in higher education — but the strata-firm version carries the trust-account overlay that other multi-entity AP doesn't.

Wrong-scheme allocation is the most common AP error at strata firms and the one with the worst downstream consequence. A misallocated cleaning invoice debits the wrong scheme's trust ledger and leaves the right scheme's ledger missing the entry; the bank account no longer reconciles to the per-scheme ledger sums; correcting the misallocation requires reversing entries on two ledgers and producing a correction trail the auditor can follow.

A firm scale also shifts where pure manual allocation breaks. Up to the first hundred schemes or so, an experienced AP clerk holds enough of the supplier-to-scheme map in working memory that classification is fast even on multi-scheme broker statements. Past that point, supplier diversity and scheme diversity outrun any one clerk's recall, and classification accuracy starts depending on system support — supplier-to-scheme rules, learned matches, or AI-driven classification — rather than on the clerk knowing every supplier's history. The firm's choice of route in that range is what the later sections on the AU strata stack and the three extraction routes work through.

GL coding to the scheme budget and budget-vs-actual variance

Every scheme has its own annual budget, approved at its AGM and resolved in the minutes. The line items map closely to the supplier mix from earlier — Cleaning Common Property, Lift Maintenance, Building Insurance, Fire Services, Garden and Grounds Maintenance, Pool Maintenance, Common-Area Electricity, Water and Sewerage, and so on for whatever facilities the scheme operates. Each invoice the AP function processes for that scheme has to be coded against the relevant line. GL coding strata scheme budget line by budget line is the operational core of how spend stays comparable to what owners voted on.

Budget-vs-actual reporting at a strata firm lives at scheme level, not firm-wide. One scheme's cleaning line can be 20 per cent over budget for the year while another scheme's is on track and a third's is under-spent because the cleaning contractor missed a fortnight. The firm rolls those scheme-level reports up for management purposes, but the meaningful unit of variance is the scheme — that's the unit the budget was set against, and the scheme's committee is the one entitled to see how its own line items are tracking.

Variance feeds back into the approval workflow. When a coded invoice pushes a budget line materially over its allocation, the AP system flags it for committee visibility even where the dollar value sits below the routine delegated-authority threshold. The threshold a strata manager uses isn't only dollar-based; it's also budget-context-based. A $300 plumbing call-out on a scheme whose plumbing line is already 80 per cent consumed in October is a different decision from the same $300 call-out on a scheme whose plumbing line is barely touched. Variance escalation gives the committee the information it needs to authorise the breach (or not) before year-end forces the question.

The budget itself is split into accounting buckets that the GL coding has to honour. Most schemes maintain an administrative fund for routine running expenses and a capital works fund — also called a sinking fund in older usage — for major replacements and longer-cycle expenditure. A roof restoration drawn from the capital works fund codes against a different line and a different fund than a routine roof repair drawn from the administrative fund. Misclassifying the two is a recurring source of variance noise; capital expenditure shouldn't draw down administrative reserves and vice versa.

A scheme's coding library is partly templated from the firm's standard chart and partly bespoke. The standard chart covers the common categories every residential scheme has. Each scheme then adds its own lines for the facilities specific to that building — a shared driveway split with the neighbouring scheme, a heritage-listed façade with its own maintenance line, a contributed lot's separate utility metering, a podium garden the scheme above contributes to. The AP system has to hold those scheme-specific lines alongside the firm-wide ones, because a coding library that flattens scheme idiosyncrasies loses the very precision the budget reporting depends on.

The approval threshold matrix — manager, committee, AGM

The approval matrix every AP clerk works against has three tiers, and each tier corresponds to a different decision-maker holding the spending authority for that band.

The manager tier covers routine maintenance and recurring supplier invoices below a delegated-authority threshold the strata manager pays without referring the invoice to the committee. Typical figures across AU schemes sit between A$1,000 and A$2,000 for routine items, but the figure that actually applies to a given scheme is the one written into that scheme's management agreement and confirmed by ordinary resolution where the committee has set its own. A scheme can lift the threshold to give the manager more discretion or lower it to keep more invoices under committee eyes; the firm's job is to honour whatever the scheme has set, not apply a firm-wide default.

The committee tier covers invoices above the manager threshold, routed through the committee for approval. In practice that approval happens through the strata software's approval portal — Strata Master's Online Invoice Approval, the Invoice Hub products on the StrataMax side, SMATA, BCP — so committee members approve from a phone or a desktop link rather than convening a meeting for each invoice. The delegated authority threshold strata invoice approval workflow is what turns a daily AP queue into something the committee can actually keep up with.

The AGM tier covers capital-works-fund draws and unbudgeted expenditure above a higher figure — commonly around A$10,000 in residential schemes, though again the actual figure is what the AGM resolution sets — and requires AGM resolution rather than committee approval alone. A new lift control board paid out of the capital works fund typically clears the AGM tier; an unbudgeted lobby refit always does.

The Queensland regime offers a useful anchor for how thresholds get set when a scheme hasn't resolved its own. Queensland's default committee spending limit formula is the relevant rule: in Queensland, where a body corporate has not set its own committee spending limit by ordinary resolution, the default limit is calculated by multiplying the number of lots in the scheme by $200. A 40-lot Queensland scheme that hasn't resolved otherwise carries a default committee spending limit of $8,000. Beyond the default sits the AGM tier; below the manager's own delegated authority sits the manager tier. The same principle holds in NSW and Victoria with different specific figures, but the QLD formula is the cleanest illustration that thresholds are governed by scheme rules and state regulation rather than by firm policy alone — for context on QLD scheme records, see extracting QLD body corporate contribution notices to Excel.

Operationally the matrix is a routing field. The AP system records ApprovalLevel = Manager, Committee, or AGM against each invoice, and that field decides which queue the invoice lands in: pay-without-approval for manager-tier items, the committee approval portal for committee-tier items, the AGM-resolution holding queue for AGM-tier items waiting for the next general meeting. The committee approval matrix strata invoice routing depends on isn't conceptual — it's a per-invoice decision the system makes the moment the invoice is coded and allocated.

The threshold table has to be per-scheme rather than firm-wide. Every scheme carries its own delegated-authority limit in the management agreement, its own ordinary-resolution committee limit if one has been set, and its own AGM-resolved threshold for capital-works draws. A firm-wide threshold table would treat schemes as interchangeable, which they aren't.

The variance-escalation linkage from the prior section sits on top of the dollar matrix. An invoice below the manager threshold can still escalate to committee visibility when the scheme's budget context demands it — the threshold matrix is the floor, and budget-driven escalation is what runs over the top of it.

Trust-ledger discipline as the AP constraint

Strata firms hold scheme funds in statutory trust accounts under state Fair Trading regulation. In NSW the framework sits under the Property and Stock Agents Act 2002 alongside the Strata Schemes Management Act 2015. In Victoria the relevant instruments are the Estate Agents Act 1980 and the Owners Corporations Act 2006. In Queensland it's the Agents Financial Administration Act and the Body Corporate and Community Management Act 1997, with the Property Occupations Act sitting alongside. Each scheme's funds are tracked in a trust ledger; paying an invoice debits that scheme's trust ledger and the bank account; the cashbook records the disbursement; three-way reconciliation matches the trust ledger sums, the cashbook, and the bank statement monthly. The trust account allocation strata supplier invoice flows through is what gives the regulator confidence that scheme funds are being held as scheme funds.

The point worth stating directly: an invoice allocated to the wrong scheme is a trust-account compliance issue, not just a coding error. The wrong scheme's trust ledger has been debited for an expense it never incurred. The right scheme's trust ledger is missing an entry that should be there. The bank account no longer reconciles to the per-scheme ledger sums on a strict reading. The auditor reviewing the trust account for the affected schemes will see the error in the ledger position itself, not as a misclassification noted in a coding report.

Correcting a misallocation isn't a one-step fix. The original entry has to be reversed against the wrong scheme's ledger; a fresh entry has to be made against the right scheme's ledger; the cashbook has to record both legs; and the correction trail has to be intact enough that an auditor reviewing the affected schemes' positions can follow what happened, when, and why. Where the misallocation crosses a reconciliation boundary — caught in May for an April-paid invoice, say — the prior month's reconciliation has to be re-run with the correction acknowledged. The cost of catching the error after payment is meaningfully higher than catching it before, and both are higher than not making it.

This positions the AP function as the gatekeeper of trust-ledger accuracy. Every misallocation that passes the AP step has to be unwound at the ledger step. The economics push every dollar of investment in classification accuracy upstream — into how reliably the AP function gets each invoice on the right scheme the first time — rather than downstream into reconciliation tooling. The reconciliation discipline matters and is its own subject, walked in detail in Australian real estate trust account three-way reconciliation, but reconciliation is what catches and surfaces errors after the AP function has made them, not what prevents them.

The Australian strata software stack — what each product does in the AP layer

AU strata software vendors compete on AI invoice ingestion, but the products aren't doing the same work. Some cover the full ingestion-to-approval cycle; some focus on the approval module with extraction handled separately; some cover the approver chain only; some integrate ingestion into an established trust ledger. A firm shortlisting on capability rather than messaging needs to see what each product genuinely covers in the AP layer, because the gaps a firm has to solve outside its strata package depend on it.

MRI Strata Master is the long-running incumbent across NSW and Victoria, with the Strata Master Online Invoice Approval module layered on top for committee-tier routing. The OIA module is centred on the approval workflow itself — committee members click an emailed link, see the invoice, approve or reject — with extraction generally handled by a separate ingestion product or by manual entry into Strata Master. Firms running Strata Master tend to solve extraction upstream rather than expecting the OIA module to do it.

StrataMax and BC Max are the corresponding incumbents on the Queensland side, with the StrataMax BCHQ Invoice Hub approver workflow integrating invoice ingestion against the existing trust ledger. Strength here is the closeness of the AP module to the ledger — invoices that approve through BCHQ post directly against the right scheme's trust ledger without a separate hand-off — and the trade-off is that ingestion choices are constrained to what the platform offers natively.

StrataPort positions itself as the AI-native option in the AU stack, with StrataPort AI invoice processing marketed as full-cycle: AI extracts header and line-item data from the invoice PDF, AI matches the invoice to a scheme and a supplier, and the matched invoice flows through the rest of StrataPort's workflow. Firms evaluating StrataPort against incumbents are weighing AI-native ingestion plus integrated workflow against the depth of trust-ledger and reporting features the older platforms have built up.

SMATA covers the approver chain with SMATA invoice processing rules at its core: rules-based routing decides which approver sees which invoice, with override and approve available at the approver step for cases the rules don't cover. SMATA is often paired with another extraction product upstream rather than asked to handle extraction itself; its strength is the routing layer between AP and the committee.

BCP Strata Invoice Hub is committee-approval-focused — the workflow that connects the firm's AP function with the committee for above-threshold sign-off, with a portal experience designed for non-finance committee members rather than a general-purpose finance UI.

The clearer way to compare these products is by capability layer rather than by product. There are four layers in the AP stack at a strata firm: extraction (turning the PDF into structured data), classification (matching the invoice to a scheme and supplier), approval routing (manager, committee, or AGM), and trust-ledger integration (posting the entry against the right scheme's ledger). Strata Master and StrataMax cover the trust-ledger integration layer themselves and often leave extraction to be solved upstream. StrataPort covers extraction and classification natively and integrates downstream. SMATA and BCP focus on the approval-routing layer with extraction handled by other tools. None of these products covers all four layers equally well, and none of them should be expected to.

That's the honest framing: there's no winner in the AU strata stack for AP, only fit. Product fit depends on firm scale, on which strata package the firm has already adopted, on which AP layer the firm needs the most help with, and on whether the firm prefers full-cycle integration or best-of-breed coverage of each layer separately. A firm running Strata Master with a clean trust-ledger setup but a growing classification problem doesn't need to switch platforms; it needs to solve the extraction and classification layer upstream of OIA. A firm running StrataPort end-to-end is making a different bet about where AI fits.

Vendor pages alone won't tell a firm any of this. Each vendor describes what its own product does, not what other products do or where the layer boundaries between them sit. Cross-product framing is what a real shortlist depends on.

Three extraction routes by firm scale

Once a firm has settled which strata package sits at the centre of its workflow, the next question is how invoices get into it. Three routes cover the field, and each fits a band of firm scale before it breaks.

Route 1 — manual entry into the strata software. The AP clerk reads each PDF, classifies the scheme, codes the GL line, attaches the PDF, and sends through the approval workflow. There's no extraction tool in the loop; the clerk is the extraction engine. This route is sustainable up to roughly 2,000 invoices a year, where one or two AP clerks can keep up without backlog and where the supplier-to-scheme map fits in working memory. Past that, manual entry starts costing the firm in throughput and in classification errors as the clerk's recall is asked to stretch over too many schemes and suppliers.

Route 2 — OCR-assisted entry within the strata package. The strata package's built-in OCR pulls header data from the PDF — invoice number, date, supplier, total — and the clerk classifies the scheme, codes the GL line, and routes the invoice into the approval workflow. This route is sustainable to roughly 6,000 invoices a year. It breaks not when the OCR struggles with the data but when classification becomes the bottleneck rather than data entry. OCR speeds up the typing; it doesn't speed up the decision about which scheme an invoice belongs to. Firms in the 100 to 300 scheme range running on Route 2 tend to find the AP team's day filling up with classification calls rather than data-entry work, which is the signal the route has reached its scale ceiling.

Route 3 — pre-strata-software AI extraction with full classification. AI extracts header and line items, classifies scheme and supplier, suggests GL coding, and the clerk reviews exceptions rather than processing each invoice from scratch. The structured output flows into the strata package downstream — sometimes through a structured-data import, sometimes via the API of the strata package, sometimes posted manually for platforms that don't accept ingestion. Route 3 is sustainable beyond 10,000 invoices a year and matches the firm scale where classification, not data entry, has become the constraint. AI supplier invoice extraction for strata and body corporate firms is what this route looks like in practice.

Route 3 is a different operating model rather than a faster Route 2. The AP clerk is reviewing exceptions instead of processing each invoice from scratch, which inverts the time profile: the firm invests time once in setting up extraction prompts and classification rules, and the daily work shifts to handling the cases the system surfaces as uncertain. A firm at this scale typically needs the structured data well before the strata software's approval module sees it — for budget-vs-actual reporting that has to refresh more often than monthly, for capital-works tracking across active projects, and for the broker pro-rata splits that don't fit cleanly into a single scheme's invoice queue. The structured output (Excel, CSV, or JSON) feeds the firm's reporting layer alongside its strata package.

How extraction works at this scale is straightforward to describe. The firm uploads a batch of supplier invoice PDFs and writes a prompt describing what to extract and how to structure it: invoice header fields, line items if they're needed for project costing, supplier, scheme identifier where the invoice carries one. The AI returns structured data with each row referenced back to the source PDF and page, which preserves the audit trail covered later in this article. Batch capacity is itself a route-fit constraint: an end-of-month catch-up at a 300-scheme firm can be several thousand invoices in one push, and a route that forces those into smaller batches stops fitting at this scale.

The evaluation framework for choosing among the routes is firm-specific rather than generic. Strata management firm AP automation evaluation comes down to invoice volume per year, number of schemes, supplier diversity, classification accuracy required, and integration approach with whichever strata package sits at the centre. The same logic applies to multi-entity AP outside strata; the broader picture sits in the multi-location accounts payable automation framework, and the strata-firm version is that framework with the trust-account overlay added. None of the three routes is wrong; the wrong choice is staying on a route the firm has outgrown.

Audit-trail discipline and the trust-account audit pack

Trust-account audits are conducted under the relevant state regime and look for specific things from the AP side. In NSW, the Property and Stock Agents Act 2002 sets the audit-pack expectations for agency trust accounts, with the Strata Schemes Management Act 2015 carrying the scheme-fund provisions that the AP records have to support. In Victoria, the Estate Agents Act 1980 and the Owners Corporations Act 2006 sit alongside Consumer Affairs Victoria's record-keeping framework and the myCAV registration obligations. In Queensland, the Agents Financial Administration Act and the Body Corporate and Community Management Act 1997 govern, with the requirement that trust-account reconciliation be completed within five business days of end-of-month being the cleanest state-specific pacing rule for the AP function to plan around. Each state also has its own Fair Trading or equivalent regulator running the audit relationship — NSW Fair Trading, Consumer Affairs Victoria, the Office of Fair Trading Queensland.

What the auditor will look for from the AP side is consistent across the regimes: who approved each invoice, when the approval happened, against which budget line the invoice was coded, paid from which trust ledger, and evidenced by which document — the supplier invoice itself plus whatever internal approval record the AP system keeps. A sample of invoices will be pulled and traced through each step. If any step is missing — an approval timestamp without a recorded approver, a payment without a linked invoice document, a trust-ledger entry without a corresponding cashbook entry — the auditor flags it and asks for explanation.

Audit-trail discipline is what makes the audit pack a by-product of the AP workflow rather than a separate compilation step. If the AP system records approval level, approver identity, approval timestamp, GL coding, scheme allocation, and trust-ledger entry alongside each invoice as the work happens, the audit pack assembles itself when the auditor asks for it. If those fields are kept in separate spreadsheets or reconstructed at audit time from email approvals, ledger entries, and PDF copies stored across different folders, gaps surface and the auditor's confidence drops — not just in the specific invoices the gap appeared on, but in the firm's process more broadly.

A practical reality is that auditors sample-test rather than review every invoice. A firm processing 12,000 invoices in a year might have 80 of them sampled across the audit. The implication is the AP workflow has to be reliable on the unselected items as well as the selected ones. An auditor who finds the eighty sampled invoices clean infers the rest are likely clean; an auditor who finds two of the eighty with gaps tends to expand the sample, and the sample expansion is where audits run long and findings accumulate.

Document retention sits alongside the workflow discipline. The supplier invoice itself, the approval record, and the trust-ledger entry have to remain accessible for the statutory retention period — typically seven years across the AU regimes, sometimes longer for capital-works documentation tied to a defects-liability period. The retention is on the firm, not on the strata software vendor; if the firm migrates platforms, the prior platform's records have to be exportable in a form the firm can keep accessible.

Edge cases that test the workflow

The cases below aren't unusual at strata-firm scale; they're the recurring share of AP work that doesn't fit the straightforward single-scheme allocation pattern, and the workflow has to handle them as routine.

Supplier credit notes and refund invoices. A credit note must reverse the original allocation precisely — same scheme's trust ledger, same budget line, same fund — and the cashbook has to record the reversal alongside the original disbursement. A credit note miscoded as a fresh expense (it happens when the credit is keyed without reference to the original invoice) doesn't reverse the position, it adds a new positive entry on top of an unchanged negative one and produces a ledger that says the firm spent twice rather than recorded a refund. The reversal pattern is mechanical, but it depends on the AP function holding the original invoice's coding and allocation in its records, which not every workflow does well.

Supplier statement reconciliation against per-scheme ledger entries. Brokers, building managers, and other multi-scheme suppliers issue periodic statements summarising what they've billed across all schemes the firm holds with them. Reconciling those statements against the per-scheme trust-ledger entries surfaces missing allocations (an invoice the broker billed but the firm hasn't recorded against the relevant scheme), duplicated allocations (the same invoice posted twice against the same scheme by mistake), and discrepancies in the amounts allocated (a pro-rata split that didn't match the supplier's intended split). Statement reconciliation is one of the cleaner controls on classification accuracy and is worth running monthly even where time pressures push to make it quarterly.

GST treatment by scheme. Schemes vary on GST registration: large mixed-use schemes with commercial lots are often GST-registered and handle the input tax credit on supplier invoices accordingly; typical residential schemes are not GST-registered and treat the same supplier invoice as input-taxed, with the GST forming part of the expense rather than being recoverable. The AP workflow has to apply the right treatment per scheme rather than running one rule firm-wide. A residential-scheme invoice posted as if the scheme could claim the GST inflates the recoverable position; a commercial-scheme invoice posted as input-taxed leaves a recoverable credit unclaimed. Both errors surface at BAS time, and both are avoidable at the AP step if the system holds the scheme's GST status as a flag against the trust-ledger entry.

Recovery from supplier billing errors. When a supplier invoices the wrong scheme — a plumbing contractor billing Scheme A for work done on Scheme B, an electrician billing the management firm directly when the work was scheme-specific — the firm has to reverse the allocation, re-issue against the correct scheme, and ensure the trust-ledger correction is visible to the affected scheme's committee. The committee for Scheme A is entitled to see that an erroneous charge was reversed; the committee for Scheme B is entitled to see that a new charge it didn't initially see was applied. Hidden corrections, even when they're benign, erode committee confidence in the firm's books when they're discovered later. The workflow requirement is that corrections surface to committees as visible events rather than disappear as silent ledger reversals.

These edge cases also feed downstream into scheme-level disclosure. When a lot in a scheme is being sold, the disclosure certificate the seller's lawyer prepares relies on the scheme's trust-ledger position and AP record being clean — outstanding contributions, pending litigation, capital-works fund balance, supplier credit positions. Misallocations and unresolved corrections that haven't been worked through surface at this point and create disclosure risk for the firm. The technical mechanics of disclosure-certificate extraction across the AU regimes are walked in Australian strata disclosure certificate extraction across NSW, VIC and QLD; the AP-side discipline is what makes those certificates straightforward to produce in the first place.

The practical takeaway is that edge cases aren't exceptions in the strict sense — they're a recurring share of the AP workload at any firm past its first hundred schemes. A workflow designed only around the clean single-scheme path will manage the bulk of invoices fine and stumble repeatedly on the cases above. A workflow designed to handle credit notes, statement reconciliation, GST variation, and supplier billing errors as routine work absorbs them without producing recurring trust-ledger corrections downstream.