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 AP structurally different from corporate AP.
Scale forces the issue. A mid-sized firm can be responsible for hundreds of schemes and thousands of 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 systematically across many schemes and the trust-account auditor's findings become a regulatory matter.
This is the firm-side AP problem, not the lot-owner levy-notice problem; the latter sits in the NSW strata levy notice extraction workflow and its state-specific companion articles.
The AP workflow has four pillars: scheme allocation, GL coding to the AGM-approved budget, manager-committee-AGM approval routing, and trust-account discipline. Two decisions run through those pillars: where each AU strata software product sits in the AP layer, and which extraction route fits the firm's invoice volume.
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.
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 recurring AP lines mirror the supplier mix: cleaning, building management, lift maintenance, fire services, building insurance, garden and grounds maintenance, pool maintenance, common-area utilities, professional services and capital works trades. Scheme-level GL coding is how each invoice stays comparable to the budget line owners approved.
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, and the admin-versus-capital-works coding rules under NSW, QLD and VIC owners-corporation law are what determine which fund an invoice is properly drawn from in any given scheme.
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. Delegated-authority thresholds turn the daily AP queue into a set of approvals 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. That allocation trail is what gives the regulator confidence that scheme funds are being held and disbursed 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.
For most firms, the practical question is fit: current strata package, firm scale, the AP layer causing the most friction, and whether the firm wants full-cycle integration or separate best-of-breed tools. 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 it through the approval workflow. There's no extraction tool in the loop; the clerk is the extraction engine. This fits low-volume books where the supplier-to-scheme map still fits in working memory. Past that, manual entry starts costing the firm in throughput and in classification errors.
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 breaks 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.
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 fits firms 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.
At this scale, the firm uploads supplier invoice PDFs and prompts for the header fields, line items, supplier and scheme identifier. The AI returns structured data with each row referenced back to the source PDF and page, preserving the audit trail while letting large month-end batches move through one route.
Choose the route by invoice volume, number of schemes, supplier diversity, required classification accuracy, and how the chosen strata package accepts structured data. 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: NSW, Victoria and Queensland all test whether scheme funds, approvals, cashbook entries and trust-ledger postings can be followed cleanly from source document to payment. The AP file is where that evidence chain begins.
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.
Document retention sits alongside the workflow discipline. The supplier invoice, approval record and trust-ledger entry have to remain accessible for the statutory retention period, and that obligation stays with the firm if it later migrates strata software platforms.
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.
These edge cases are routine at strata-firm scale. A workflow that handles credit notes, statement reconciliation, GST variation, and supplier billing errors as normal AP work prevents recurring trust-ledger corrections downstream.
Extract invoice data to Excel with natural language prompts
Upload your invoices, describe what you need in plain language, and download clean, structured spreadsheets. No templates, no complex configuration.
Related Articles
Explore adjacent guides and reference articles on this topic.
Australian Strata AP: Admin vs Capital Works Fund Coding
Code Australian strata supplier invoices to the right scheme and fund — admin vs capital works, sinking, or maintenance plan — under NSW, QLD and VIC law.
Extract NSW s184, VIC s151 & QLD Form 33 Strata Certificates
NSW Section 184, VIC s151 OC, and QLD Form 33 strata certificates side by side: disclosures, buyer-side red flags, and the multi-lot extraction shape.
Extract QLD Body Corporate Contribution Notices to Excel
Extract QLD body corporate contribution notices to Excel, with administrative fund, sinking fund, special contributions, due dates, discounts and arrears.