Expense intelligence & tax automation platform¶
Executive summary¶
The bank has a strategic opportunity to own the financial operating system for sole traders, SMEs, and property investors across NZ and AU — a segment currently underserved by every incumbent bank and only partially addressed by neobanks.
The core insight: transaction classification happens too late, in the wrong system, with the wrong tools. Today the flow is:
Bank → dump raw transactions → Xero → manual rules → hours of cleanup
What it should be:
Bank → classify in real time → learn → output accounting-ready, tax-compliant data
No bank has solved this end-to-end. Monzo has the best merchant enrichment UI in the world. Starling has a business wrapper. Hnry (NZ/AU) auto-withholds and pays PAYE and GST for sole traders — but is not a bank. The first bank to natively solve expense intelligence will own this segment.
The problem: five hours in Xero¶
The experience that motivated this capability: a user spending five hours configuring Xero rules to reconcile six months of mixed sole-trader/personal transactions.
This is not a niche pain point. It is the dominant experience for the ~250,000 sole traders in NZ and ~2 million in AU who:
- Mix personal and business spend on the same account or card
- Manually create Xero/MYOB rules that break when merchants change
- Rework historical data after forgetting to classify transactions
- Struggle to separate GST-claimable from non-claimable in real time
- Cannot easily generate a GST return without accountant involvement
The bank that eliminates this workflow wins loyalty from these customers at a level no interest rate or fee waiver can match.
Target personas¶
Sole trader¶
The most common and most underserved. A graphic designer, contractor, or consultant using a personal account for everything. No separation between their person and their business — legally they are the same entity. Needs: - Automatic personal/business split - GST-claimable categorisation - Quarterly GST return preparation - Income tax provisional tax estimation
SME (Ltd company)¶
A director using a company card and personal card interchangeably. Or a small team where one person manages expenses. Needs: - Business account with clean classification - Expense reimbursement workflows - Company vs director personal split - Xero integration that sends clean, pre-classified data
Employee with business expenses¶
No company account — uses personal card, claims back. Needs: - Easy one-tap "this is a business expense" tagging - Receipt capture and storage - Export for reimbursement claim (PDF, CSV, or Xero) - Policy awareness ("alcohol is not claimable")
Property investor¶
One to several rental properties, often managed through a personal account with no separation. Not a business. Needs: - Property-level income and expense tracking - Ring-fenced loss tracking (NZ) - GST position (commercial only) - Tax-ready rental schedule output
Multi-entity individual¶
One person who is simultaneously: themselves personally, a sole trader, a director of two Ltd companies, and treasurer of a local charity. Needs: - A single login to see all entities - Clean separation of context without managing multiple apps - Appropriate access controls per entity
From enrichment to intelligence: the progression¶
What Monzo does (the baseline)¶
- Merchant name normalisation and logo
- Location pin and map
- Basic spend category
- Merchant grouping (all Starbucks branches = one merchant)
- Trip grouping
This is description — what happened, where, and with whom.
Step 1: Why it happened (contextual intelligence)¶
- Behavioural baselining: "You usually spend £25 here — this was higher"
- Time/context: "This matches your Friday lunch pattern"
- Classification signal: "This looks like a business meal vs personal dining"
Requires: behavioural baselining, time-of-day + location context, peer comparison (privacy-safe aggregates only).
Step 2: Intent classification (beyond static categories)¶
Move from "Eating out" to: - "Quick lunch near office" (non-claimable commute) - "Client dinner" (claimable entertainment, subject to rules) - "Travel dining" (claimable when on a business trip) - "Work expense candidate" (high confidence, needs confirmation)
Step 3: Merchant graph + entity resolution¶
Group merchants into relationship graphs: - "These 3 cafés are within 300m of your registered office address" - "This is a new merchant outside your normal pattern" - Enable: anomaly detection, habit visualisation, fraud signal strengthening
Step 4: Spatiotemporal intelligence¶
Beyond location pins: - Detect trips automatically: flights + accommodation + local spend = "4-day business trip to Auckland" - Detect commute patterns: repeated routes = non-claimable commute (NZ/AU rules) - Trip summaries: FX spend, per diem tracking, receipts grouped by trip
Step 5: Real-time decisioning¶
Before / during payment: - "This looks like a duplicate subscription" - "You're about to exceed your dining budget" - "This price is higher than your usual for this merchant"
Step 6: Automation (do things on behalf of the user)¶
- Auto-split bills
- Auto-expense claims (business vs personal based on learned pattern)
- Savings automation: "You underspent this week — move $50 to savings?"
- GST estimation: "You've accumulated $430 in reclaimable GST this quarter"
Step 7: Forward-looking intelligence¶
- "If you keep spending like this, you'll save $X by June"
- "Cut dining by 15% → save $Y/month"
- Provisional tax estimation (sole traders, NZ/AU)
- Cashflow forecasting by category
Advanced classification engine¶
Multi-dimensional classification matrix¶
Every transaction receives a multi-dimensional classification, not a single category:
| Dimension | Values | Example |
|---|---|---|
| Ownership | Personal / Business / Mixed / Property | Business |
| Purpose | Client meeting / Supplies / Commute / Travel | Client lunch |
| Tax treatment | Fully claimable / Partially claimable / Non-claimable | 50% claimable (entertainment) |
| Accounting mapping | Chart of accounts code | Meals & Entertainment |
| Confidence | 0–100% | 87% |
| Classification basis | Merchant / Behavioural / Geo / Rule / User-confirmed | Behavioural |
Classification inputs¶
Merchant intelligence: - Normalised merchant name and industry code (MCC) - Prior classification of this merchant in user's history - Population-level classification signal (privacy-safe: "most users classify AWS as business")
Behavioural pattern: - Weekday vs weekend - Time of day - Recurrence (weekly subscriptions = likely business software) - Spend amount vs baseline - Sequence (flight + hotel + meals within same period = business trip)
Geo-spatial context (see section below)
User-confirmed rules: - "This merchant is always business for me" - "Uber rides between 8–9am weekdays are personal commute" - Rules are learned implicitly from user confirmations, not built explicitly
Graph relationships: - Transactions linked to prior classified transactions at same merchant - Calendar integration (opt-in): "This transaction matches a calendar event with a contact" - Xero/MYOB transaction history (import on onboarding to bootstrap the model)
Geo-spatial intelligence layer¶
Location clustering¶
For each user, maintain: - Home cluster: transactions within typical home radius - Work cluster: transactions near registered business address or frequent weekday location - Travel clusters: locations outside home/work patterns
Classification by cluster¶
| Transaction location | Time | Signal |
|---|---|---|
| Within work cluster | Business hours weekday | Strong business signal |
| Within home cluster | Evening/weekend | Strong personal signal |
| Outside both clusters | Sustained sequence | Travel period |
| Same geo sequence as prior trips | Similar duration | Recurring business travel |
Trip detection¶
Automatic detection when: - A flight (or departure from home city for >1 day) is detected - Local transactions cluster in a new geography - Return to home geography closes the trip
Output: Auto-grouped trip summary with: - Total spend by category - FX conversion costs - Business vs personal split - Receipt gap identification ("3 meals with no receipts — add them?")
Commute detection¶
In NZ and AU, commute costs are not tax-deductible (travel from home to a fixed place of work). The system should: - Detect repeated home→work routes (Uber, public transport) - Auto-classify as "Commute — non-claimable" - Distinguish from travel to client sites (claimable)
Auto rules engine¶
The problem with Xero-style rules¶
Manual rule creation is: - Time-consuming (as demonstrated by the 5-hour setup scenario) - Brittle (breaks when merchant name format changes) - Non-adaptive (cannot learn from exceptions) - Retrospective (doesn't help with real-time classification)
Implicit rule creation¶
Every user action creates a rule candidate: - User confirms "this is business" for Merchant X → candidate rule: "Merchant X = Business" - User marks 5 consecutive Tuesday morning coffees as commute → candidate rule: "Coffee near home, Tue–Fri morning = Personal commute" - System promotes candidates to active rules at a confidence threshold
Rule types supported¶
| Rule type | Example |
|---|---|
| Merchant | "Adobe Creative Cloud" → always Business, Software & Subscriptions |
| Merchant + time | "Uber" on weekday 8–9am → Personal, Commute |
| Merchant + location | "Supermarket near home" → Personal, Groceries |
| Amount range | Any transaction > $500 → prompt for review (not auto) |
| Recurrence | Same amount, same merchant, monthly → Subscription, confirm type |
User interaction (minimal friction)¶
Rather than a rules setup screen, the user interacts through confirmations: - "You paid Adobe again — same as last month's Business Software?" [Confirm / Change] - "You often mark these as commute — should we do that automatically?" [Yes / Not always] - No setup phase. Rules emerge from use.
Confidence thresholds¶
| Confidence | System action |
|---|---|
| ≥ 95% | Auto-classify, no prompt |
| 70–95% | Apply classification, show brief note, easy override |
| 40–70% | Surface as suggestion, one-tap confirm |
| < 40% | Present for manual review |
User experience design¶
Daily workflow¶
User opens app and sees a triage queue:
"4 transactions to review — takes about 30 seconds"
Each transaction shows: - Enriched merchant name + logo - Suggested classification with confidence indicator - Swipe right → Business / Swipe left → Personal / Tap → Split or more options
The goal: zero setup, near-zero daily effort, increasing automation over time.
Transaction split¶
Many transactions are genuinely mixed (lunch with a client where you paid for yourself and them): - % split (e.g. 60% Business / 40% Personal) - Line-item split (if receipt captured) - "Same split as last time?" prompt on same merchant
Receipts¶
- Camera capture in-app
- Email parsing (forwarded receipt emails)
- OCR extracts: total, GST component, merchant, date, line items where possible
- Auto-match to pending transaction
- "3 transactions without receipts this week" nudge
Business expense summary¶
Persistent widget or card:
"This month: $2,840 business expenses | $412 GST reclaimable | 2 receipts missing"
GST readiness indicator¶
As the end of the GST period approaches:
"Your next GST return covers 1 Jan – 31 Mar. We have 94% of transactions classified. 6% need your review."
GST and tax rules¶
New Zealand¶
GST rate: 15%
Claimable: Expenses incurred in the course of making taxable supplies. Standard business expenses — software, equipment, professional services, travel for business, meals with clients (partially), advertising.
Not claimable: - Private/personal use - Residential rent (exempt supply — no GST in or out) - Entertainment: meals/drinks entertainment is 50% claimable (Entertainment Tax Rules) - Fines and penalties
Entertainment rules (important): NZ entertainment deductibility limits apply to meals, beverages, and social events. The "non-deductible entertainment" rules limit deductibility to 50% for most food and beverage. The system should flag this and apply 50% by default for meals categorised as entertainment.
Sole trader GST return outputs: - Box 5: Total sales and income (including GST) - Box 6: Zero-rated supplies - Box 11: Purchases and expenses (including GST) - Box 13: Credit adjustments / GST on imports
Provisional tax: For sole traders earning > $5,000 in residual income tax. System should estimate provisional tax liability from transaction data. Output: "Your estimated provisional tax liability this year is $X — consider setting aside $Y/month."
Interest deductibility note: The Labour government's interest limitation rules (introduced 2021) were fully reversed by the National government. From 1 April 2025, residential rental interest is 100% deductible. The system must handle historical periods (50% deductible in 2023/24, 80% in 2024/25) and should be designed for future rule changes.
Australia¶
GST rate: 10%
Claimable: Business expenses incurred in earning assessable income. Input tax credits on GST-registered business purchases.
Not claimable: - Private use - Residential rent (input-taxed supply) - Wages - Motor vehicle expenses (limits apply; log book method supported) - Entertainment: similar 50% restriction on meal entertainment
BAS outputs: - G1: Total sales - G2: Export sales - G3: Other GST-free sales - G10: Capital purchases - G11: Non-capital purchases - 1A: GST on sales / 1B: GST on purchases
Instant Asset Write-Off: The system should flag capital items that may qualify for immediate deduction under the IAWO threshold (changes annually — needs versioned rule set).
International note¶
For UK/EU expansion: VAT rates vary (20% standard, 5% reduced, 0% zero-rated) and rules on partial reclaim for mixed businesses are complex. The tax logic engine must be jurisdictionally modular — NZ and AU rules at launch, UK/EU rule sets added independently.
Rental property income tracking and ring-fencing¶
The core concept: property as a virtual business unit¶
A rental property is not a legal entity. The owner may be a natural person, a company, a trust, or joint owners. But for tax and reporting purposes it behaves like a business: it has income, deductible expenses, a tax position, and (in NZ) ring-fenced losses.
The system treats each property as an operating context — a non-legal but economically meaningful unit with its own ledger, P&L, and tax profile. See Customer, party and user schema for the data model.
Rental income detection¶
- Regular inbound payments with consistent amount and/or tenant reference
- System prompts: "We've detected regular payments that look like rent — is this from a tenant at [address]?"
- Manual confirmation on setup; auto-attribution thereafter
Expense categorisation (rental-specific)¶
| Category | Examples | Tax treatment (NZ) |
|---|---|---|
| Operating — repairs & maintenance | Plumber, electrician, painter | Fully deductible (if not capital) |
| Operating — rates & insurance | Council, insurance provider | Fully deductible |
| Operating — property management | Agent fees | Fully deductible |
| Financing — mortgage interest | Bank payment | Fully deductible from 2025/26 |
| Capital expenditure | New roof, extension, kitchen replacement | Depreciable (not immediately deductible) |
| Mixed personal/rental | Utilities on holiday home | Apportioned |
Capital vs revenue: The system should flag large repair/improvement transactions for user confirmation on treatment. "Is this a repair (deductible now) or an improvement (capital)?" This is a common source of error and IRD audit interest.
Ring-fencing (NZ)¶
Under the residential ring-fencing rules (Income Tax Act 2007, ss EE 1–8), rental losses from residential property cannot offset other income (salary, business income). They must be carried forward and offset only against future rental profits from the same or other rental properties.
System behaviour:
- Calculate property-level net income each period: rent received minus deductible expenses
- If profit: normal income, forms part of total taxable income
- If loss: ring-fenced. System records the loss separately, carries forward, and applies it to future rental profits
- Portfolio-level offset: ring-fenced losses from Property A can offset profits from Property B
| Property | Period | Net result | Ring-fenced carry-forward |
|---|---|---|---|
| 12 Smith St | Year 1 | −$5,400 | $5,400 |
| 12 Smith St | Year 2 | +$3,200 | $2,200 remaining |
| 24 Oak Ave | Year 1 | +$1,800 | $400 remaining (offset against portfolio) |
Exemptions from ring-fencing (system must handle): - Portfolio profitability test: if the combined portfolio is profitable, losses need not be ring-fenced - Land business (developers/dealers): different rules apply - Mixed-use holiday homes: specific bright-line/mixed-use apportionment rules
Holiday home / mixed-use property¶
A property rented part-time and used personally part-time: - Income days vs personal use days vs empty days - Expense apportionment by use-days formula - System tracks: calendar integration optional, or manual input of days per period - Output: deductible portion of expenses per period
GST on rental¶
| Property type | GST treatment |
|---|---|
| Residential rental | Exempt supply — no GST, no input tax credits |
| Commercial rental | Taxable supply — 15% GST on rent, input tax credits on expenses |
| Mixed residential/commercial | Partial input tax credit based on taxable use % |
Accounting integration and output layer¶
Internal outputs (no integration needed)¶
- Expense ledger by category
- Property P&L by period
- GST return summary (ready to file or review)
- Provisional tax estimate
- Ring-fenced loss register
Xero integration¶
Xero API (OAuth 2.0) supports: - Push pre-classified transactions with tax codes - Create bank transactions with account/tracking category pre-populated - Attach receipts as file attachments - Create draft GST returns (manual review before filing)
User benefit: Xero becomes a review step, not a classification step. The bank does the work; Xero is the output and accountant interface.
MYOB integration¶
MYOB AccountRight/Essentials APIs offer similar functionality. Relevant for AU market where MYOB has stronger SME penetration.
Direct GST/BAS filing¶
Phase 3 target: Direct lodgement via: - NZ: IRD Gateway Services (myIR API) for GST returns - AU: ATO SBR2 (Standard Business Reporting) for BAS
This removes the accounting platform entirely for simple cases. A sole trader or property investor with straightforward accounts could file GST directly from the bank app.
Accountant mode¶
For users who have an accountant: - Read-only accountant access (via Access_Grant — see schema) - Shared view of classified transactions, tax position, and receipts - One-click export (ICFM, CSV, Xero-compatible format) - Audit trail: explanation of every auto-classification decision
Competitive landscape¶
| Player | Strengths | Weaknesses | Relevance |
|---|---|---|---|
| Hnry (NZ/AU) | Auto-withholds PAYE, GST, income tax for sole traders. Deep IRD integration. | Not a bank — sits on top of one. No investment property support. No multi-entity. | Primary benchmark. The feature set we must exceed. |
| Monzo Business | Best-in-class merchant enrichment UI. Receipt capture. | Weak automation. No GST-ready outputs. No property support. | UX benchmark |
| Starling Bank | Business toolkit, invoicing, tax pots. | Still rules-based, limited learning. UK-focused. | Structural reference |
| Mercury | Clean UI, accounting integrations. | Pushes problem to Xero/QuickBooks. US-focused. | Integration model |
| Brex | Strong for employee expense management, policy enforcement. | Corporate focus, not sole trader. | Employee expense reference |
| Xero | Full accounting platform, rules engine, bank feeds. | Requires manual rule creation (the 5-hour problem). Not a bank. | The tool we reduce reliance on |
| ANZ/ASB/Westpac (NZ) | Established brand, broad product range. | Essentially zero transaction intelligence. No automation. | The market to take from |
The gap: No existing bank provides intelligent, real-time personal/business classification that learns from behaviour, applies NZ/AU tax rules, and produces filing-ready outputs natively.
Architecture implications¶
New capabilities introduced by this platform¶
| Capability | Description | Goal |
|---|---|---|
| CAP-134 | Transaction intelligence enrichment (merchant, location, category) | BG-003 |
| CAP-135 | Personal/business expense classification | BG-003, BG-009 |
| CAP-136 | Sole trader & SME tax automation (GST, expense management) | BG-003, BG-009, BG-011 |
| CAP-137 | Rental property income tracking & ring-fencing | BG-003, BG-009 |
| CAP-138 | Multi-entity party model — single user across entities | BG-001, BG-011 |
| CAP-139 | Receipt capture, OCR & expense reconciliation | BG-003, BG-009 |
Modules required¶
| Module | Description | System |
|---|---|---|
| MOD-087 | Transaction enrichment engine | SD07 |
| MOD-088 | Expense classification engine (ML + rules) | SD06 |
| MOD-089 | Geo-spatial processor (clustering, trip detection) | SD06 |
| MOD-090 | Auto rules engine (user-defined + learned) | SD08 |
| MOD-091 | Receipt processor (OCR, email ingestion, matching) | SD08 |
| MOD-092 | Tax logic engine (GST, NZ/AU rules, ring-fencing) | SD06 |
| MOD-093 | Accounting mapper (Xero/MYOB APIs, IRD/ATO gateway) | SD07 |
| MOD-094 | Property attribution engine | SD06 |
| MOD-095 | Ring-fencing logic engine | SD06 |
| MOD-096 | Multi-entity party graph manager | SD02 |
See Customer, party and user schema for the data model underpinning CAP-138 and MOD-096.
Implementation phases¶
Phase 1 — Enrichment foundation¶
- Merchant name normalisation, logo, location, category (MOD-087)
- Basic personal/business toggle on each transaction (manual)
- Receipt photo capture and storage (MOD-091)
- Transaction search and filtering improvements
Phase 2 — Classification intelligence¶
- ML-based classification engine (MOD-088)
- Geo-spatial clustering and trip detection (MOD-089)
- Implicit rule learning from user confirmations (MOD-090)
- GST estimation from classified transactions (MOD-092)
- Party graph model launch: sole trader and multi-entity views (MOD-096)
Phase 3 — Tax automation and property¶
- Full GST return preparation and one-click review/file (MOD-092)
- Rental property setup and income/expense tracking (MOD-094)
- Ring-fencing logic and loss register (MOD-095)
- Xero/MYOB integration — push pre-classified transactions (MOD-093)
- Provisional tax estimation for sole traders
Phase 4 — Full automation and direct filing¶
- Direct IRD/ATO GST/BAS lodgement (MOD-093)
- Accountant access mode
- Cashflow and tax forecasting
- Multi-entity view: Ltd company accounts + personal in one view
- Employee expense reimbursement workflows
- Policy enforcement for company expense policies
Strategic value¶
For the user¶
- The "5-hour Xero session" becomes a 5-minute monthly review
- Tax compliance is ambient, not an annual event
- A sole trader who does not need an accountant for basic returns is a retained, engaged customer
For the bank¶
- SME and sole trader segment dominance. No NZ/AU bank has solved this. First-mover advantage is significant.
- Daily engagement driver. Expense classification creates daily app interaction — far higher engagement than savings balance checking.
- Data moat. A classified, enriched transaction history is a proprietary asset. It improves credit decisioning, fraud detection, and product recommendations.
- Platform licensing (BG-011). The tax logic and party model can be licensed to smaller financial institutions as a module.
- Accounting platform displacement. For simple cases (sole traders, single-property investors), the bank becomes the accounting system. This is a significant revenue opportunity if a subscription or transaction fee is applied.
The uncomfortable truth about timing¶
The window to lead this category is now. AI/ML costs are low; the Monzo enrichment benchmark is public knowledge; every neobank entrant will attempt this. The bank that builds the underlying data model correctly (see party schema) and executes the learning loop first will be very difficult to displace.