Privacy Policy

Effective date: 26 June 2026

Last updated: 29 October 2026

This policy explains how Outblock Pty Ltd (ABN 94 655 314 051) ("we", "us", "our") handles personal information in BeforeMay — a platform that helps Australian accounting firms know whether a client's tax documents are ready, classify uploaded documents with AI, and generate and review tax workpapers. We handle personal information consistently with the Privacy Act 1988 (Cth) and the Australian Privacy Principles (APPs).

We provide the platform to accounting firms (our customers). For the personal information a firm and its clients put into the platform, the firm decides how that information is used — we process it on the firm's behalf under our agreement with them. If you are a client of a firm, contact that firm first about your information; we will support them in responding to you.

Questions or requests: privacy@beforemay.com.au.

1. Whose information we handle

• Firm users — accountants and staff who sign in (owner, admin, staff roles).
• Firm clients — the taxpayers a firm serves, whose documents and contact details are processed so the firm can assess readiness and prepare workpapers.
• Portal visitors — clients invited to the portal to upload documents, confirm contact details, or view and pay invoices. An invitation is bound to the email address it was sent to and is accepted by that person while signed in under that address, so a portal visitor has an account of their own; the link is how the invitation reaches them, not the access itself.

2. What information we collect

Account & identity — name, email, phone number (where used for one-time passcodes), firm membership and role, and login/authentication metadata (including Apple or Google sign-in identifiers where used).

Documents & financial information — the files clients upload (receipts, statements, invoices and similar tax/accounting records) and the information AI or staff extract from them: merchant, date, amount, GST, category, document type, risk flags, and checklist matches. This can include sensitive financial information.

Tax File Numbers, Medicare numbers, passport and licence numbers. These are removed before anything is sent for AI processing. Every document and every instruction passes through an automated redaction step in Australia first: the identifier is detected and stripped, and the document continues on without it. Redaction is best-effort: in rare cases a file cannot be checked (for example, it is damaged or unreadable) and is processed as uploaded. We reserve the right to decide how such cases are handled.

TFN storage is separate from AI processing. Your firm can keep a TFN against your client record in Australia for exactly two purposes:

1. so your accountant can see, check and correct it while preparing your return — it also appears on the workpaper they prepare and review; and
2. so your return can be lodged. The ATO rejects a lodgement whose client details do not match its own record, so the number has to be right and has to be to hand. Today your accountant lodges from their own ATO-connected software; if we add lodgement to BeforeMay we will send your TFN to the ATO for that purpose and nothing else, and we will say so here first.

That is the whole list. We do not use your TFN to link you across firms, we do not use it for analytics or product measurement, we do not sell or disclose it, and — as above — it is never sent overseas. On screen it is hidden behind a click rather than shown by default.

Where it is no longer kept. Until 10 August 2026 a copy also sat in two places that had no use for it: the text our recognition service reads off a document, and the structured fields our AI extracts. Neither was ever read. Both have been cleared for existing documents and neither is written any more — where a TFN appeared in recognised text you will now see [TFN removed], and the extraction keeps only a note that one was present.

Your accountant's own copy of the source document is untouched — the removal applies to what we send onward and to what we index, not to the file they hold. That file is the record they are required to keep and the thing they check their work against.

What we take out before anything is sent for AI processing.

• Removed entirely — Tax File Numbers, Medicare numbers, passport numbers and driver licence numbers. These do not leave Australia by any route.
• Replaced with a code — bank account numbers and BSBs. The AI is told Account 1 and BSB 2, never the digits. Nothing in a workpaper is calculated from them; all that matters is telling one account from another, and a code does that without the number ever being sent.
• Replaced with a stand-in — phone numbers, swapped for realistic substitutes of the same kind in the text we extract. Since October 2026 a phone number is also taken out of the source document where a label such as "Phone", "Mobile" or "Tel" sits beside it on the same line. One printed with no label beside it is left in the document, because an invoice or reference number looks the same and taking it out would remove a figure.
• Replaced with an age band — dates of birth. The AI is told an age band at 30 June of the year being prepared — for example aged 67-69 at 30 June 2026 — never the date. Every rule a workpaper applies to age asks only whether a person has reached a threshold (18, 60, 65, 67, 70 or 75), and the bands are cut at exactly those ages. Where a birthday that crosses one of them falls inside the year, the month it fell in is given too, because some of those rules change on the day itself. A date of birth beside a label such as "Date of birth" is replaced in the source document as well, with the band written where the date was; one printed with no label beside it can be missed, and one we miss is sent as it appears. This began in October 2026.
• Both — email addresses. They are swapped for a substitute in the text we extract, and they are also taken out of the source document itself, so an email address does not leave Australia by either route. This became true in September 2026, when we began accepting forwarded emails as source documents; before that an email address reached us mainly inside a PDF and was left in the file.
• Both, with a code — cryptocurrency wallet addresses, blockchain transaction hashes and crypto-exchange user IDs, where we can recognise them. An address or transaction hash in a format we can recognise on its own — one with a built-in checksum (Bitcoin, Litecoin, Tron, XRP and similar) or Ethereum's fixed shape — is removed wherever we find it. Formats without either (for example a Solana address or a Bitcoin transaction hash) and exchange user IDs are removed only when they sit beside a label, or under a column heading in a spreadsheet or CSV file. The AI is told Wallet 1, TxHash 1 or User ID 1 in the text we extract, never the characters, and they are also taken out of the source document itself. Some can be missed — for example one with no label in running text, or one in a table inside a Word document or PDF — and one we miss is sent as it appears. A wallet address is a key to a public ledger: anyone who has it can see every transaction that wallet has made. The amounts, dates and coins are sent as they appear — the capital gains schedule is built from them. This began in September 2026.
• Sent as it appears — everything else, including the taxpayer's name, address, ABN, employer, balances and transaction detail. The workpaper has to tie back to the source document the accountant checks it against.

The document itself is sent as well as the text we extract from it. Only the first group above, email addresses, phone numbers and dates of birth beside a label, and the crypto identifiers we recognise are taken out of the document; bank details are not. Building a workpaper means reading the actual statement.

A page we cannot read well enough to check is not sent at all — the step stops rather than guesses.

Your accountant's own copy is untouched. All of this applies to what we send onward, not to the file they hold: that file is the record they are required to keep.

This is redaction. It is not de-identification, and we will not call it that. The list above says what is sent as well as what is not, so that you can see how far it goes rather than take a word for it. The substitutions are reversible by us, which is what makes them stand-ins rather than anonymisation. Everything we handle therefore remains personal information under the Privacy Act 1988 (Cth), and APP 8 applies to it in full. If you ever see us describe our processing as anonymised, de-identified or privacy-preserving, that description is wrong — tell us at privacy@beforemay.com.au and we will correct it.

Billing — invoice records and payment status. Card payments are taken through Stripe via the firm's own payment link; we do not receive or store full card numbers.

Communications — email "chase" content generated for a firm to send to its clients, email drafts and send logs, and inbound email we receive on a firm's behalf.

Technical & audit — IP address and request metadata used for rate limiting and security, and an audit trail of security-relevant actions (portal token use, document reads, signed-URL issuance, checklist updates, invoice reads, and contact confirmations).

Cookies & analytics — three things run in your browser when you use BeforeMay, and this is what each one is given:

• PostHog (product analytics and error reporting) — which pages of the app you open, your user id and email address, your firm's id and name, and the text of any error the app hits. It keeps a small identifier in your browser (a cookie or browser storage) so it can tell your next visit from a stranger's. Click-by-click recording and session replay are switched off in our code, not just in a setting.
• Google Ads conversion tracking — which page of the site you are on, so we can tell whether an advertisement led to a sign-up. Google sets its own cookie for this. It is never given your name, your email address, a case, a client or a figure — only the page.
• Vercel (our host) — anonymous page-view counts and page-load timing, without a cookie.

Before any of the three is told which page you are on, the address is cut back to its route: a portal or signing link, a document id or a search term never reaches them. None of them is given a client document or anything read from one. The Privacy Act 1988 (Cth) asks us to tell you this here; it does not ask for a consent banner, and we do not show one. Blocking any of the three in your browser does not affect your use of the platform.

A connected Outlook mailbox (optional). A firm member can connect their own Microsoft Outlook mailbox so the platform can show their email, bring a client's emails and attachments into that client's case, and send replies from their own address. Connecting is the member's choice, and they can disconnect at any time. When they do:

• We keep an index of the mailbox's envelopes — for each email in the window the member chooses (one year unless they choose otherwise, at most two): who sent it, who it went to, the subject line, the date, which folder it is in, whether it was read, and whether it has attachments. Only that member can see their index; their colleagues cannot.
• We keep only client email. Unless the firm turns it off (Settings → Email), email to or from a client is saved to that client's files, from the day it is on. A client's email brought into a case keeps its attachments and text there. Other email is read when opened and not stored. Copies are deleted with the client or case.
• AI sees email only after identifiers are removed: a client's email for a draft reply or for that case's work; and, when an email can't be matched to a client by address or name, its sender name, subject, opening text and attachment names with a shortlist of the firm's client names, to suggest the client. Newsletters and automated mail are excluded; addresses are never sent.
• Disconnecting the mailbox deletes its index, immediately and in full. Documents already brought into a case stay with that case.

BeforeMay in Microsoft Teams (optional). A firm can add the BeforeMay app to its own Microsoft Teams. A member who asks it something first links their Teams account to their BeforeMay account — by the same email address, or, where the two differ or Teams shows none, by signing in with Microsoft, from which we receive only the account's identifiers (its user and organisation IDs), name and email. When the firm uses it:

• We keep the messages addressed to the app, and its replies, as part of the firm's records, so a follow-up question makes sense. The firm's members can read them.
• AI sees the question and the last few messages of that chat after identifiers are removed, with the firm's own case details the answer needs — the same providers as the rest of the platform (sections 5 and 7). A question about a client's workpaper is handed to the same assistant the case page uses, which reads that case's paper and documents exactly as it does there.
• In a chat that includes anyone outside the firm, it gives no client details, and it never names a client the firm has restricted.
• A file sent to the app in a direct message is fetched from the sender's OneDrive and stored with the client, like any upload. Saving a workpaper to OneDrive puts a copy in the member's own OneDrive, which their firm's Microsoft 365 controls.
• Filing a file, opening a case and starting a build each wait for the member to press a confirmation button. A change to a workpaper is made only on the member's own instruction, and the reply lists every cell changed with a way to undo it.

We collect this information directly from firm users and from clients/portal visitors who provide it, and we generate derived information (the AI extractions above) from the documents provided.

3. How we use it

We use personal information to:

• provide the platform — document upload, AI classification, readiness tracking, workpaper generation and review, invoicing and payment reconciliation;
• run AI pre-review of documents (see section 5);
• send, on a firm's instruction, the firm's communications to its clients;
• authenticate users, scope each firm's data to that firm, rate-limit, detect abuse, and keep an audit trail;
• support, debug, and improve the platform;
• send you email about the product itself — what changed, new return types, and occasionally a plan change or offer — only if you asked us to, with a working unsubscribe on every one and no effect on mail about your own cases and account; and
• meet our legal and record-keeping obligations.

We do not sell personal information, and we do not use clients' documents or extracted financial data to train our own or any third party's general AI models.

4. Multi-tenant isolation

Every firm's data is scoped to that firm. Accountant data is protected by database row-level security keyed to firm membership; client portal access is limited to a single firm and client through a bearer token stored only as a hash and validated on every request. One firm cannot read another firm's data, and a portal visitor can only reach their own files and invoices.

5. AI processing and the human-review boundary

Uploaded documents are analysed server-side by an overseas AI provider — one of those named in the sub-processor table in section 6 — to suggest the merchant, date, amount, GST, category, risk flags, TFN presence, and checklist match. For a single document, what is sent is the file's bytes (for supported types), filename, MIME type, and candidate checklist labels.

Two other steps send more, and both are covered by that same table. Text recognition runs first, in Australia. A document that already contains text is read on our own service in Sydney. A scanned page or a photo is read either there or by Microsoft Azure Document Intelligence in its Australia East region (New South Wales), which deletes the page and its result within 24 hours; if that service is unavailable, the page is read on our own service instead — never by a provider outside Australia. When a workpaper is built or a whole case is analysed, the redacted source files and a summary of the case — including the taxpayer's name and the recognised text of their documents — are provided to the AI provider handling that step. The workpaper is then reviewed by a second provider, different from the one that drafted it, before we hand it back — a draft and its reviewer should not share the same blind spots.

Which provider handles which step is a configuration decision, not something fixed in this document. Section 6 names every provider we may use and the country each processes in; section 7 says how we tell you which applies to your firm.

Before any of that, the document passes through our own identifier-removal service, hosted in Sydney (section 6). That step is mandatory and it fails closed: if the service cannot be reached, or cannot read a page well enough to check it, the document is not sent onward and the job stops with an error. We do not fall back to sending the original.

AI output is a pre-review aid only. The final category, GST treatment, checklist match, workpaper figures, and lodgement readiness remain the accountant's responsibility. We do not treat AI output as a decision and do not auto-approve when analysis fails — those documents are flagged for human review.

6. Who we share it with (sub-processors)

We use a small set of service providers to run the platform. Each acts on our instructions and is bound by confidentiality and data-protection terms:

We share information with these providers only as needed to deliver the service, and otherwise disclose personal information only where you or the firm direct us, or where we are required or authorised by law.

7. Cross-border disclosure (APP 8)

Documents and account data are stored at rest in Australia, and everything we run ourselves — identifier removal, text recognition, and building the workpaper — runs in Australia too. So does the one recognition step a provider performs for us: Microsoft Azure reads scanned pages and photos in its Australia East region (New South Wales).

The AI steps in preparing a workpaper leave the country, for the purposes set out in the table above, to the AI providers named there and in the countries recorded beside them. Other sub-processors (including Stripe, Resend, Google, Vercel and PostHog) also process information overseas, in the United States and the European Union.

Our main AI services are Fireworks AI and Anthropic. Analysis and drafting use Fireworks AI's United States-only service; Anthropic provides independent review, also in the United States. The full sub-processor table identifies who processes customer information and where.

Retention is specific to each service (section 8). No-training terms and ZDR do not mean that the remaining information is anonymous or that processing stays in Australia. Every AI input passes through the identifier-removal step below. We tell a firm which providers handle its documents, and we tell it before that changes; ask at any time and we will confirm it in writing.

We name the countries rather than saying "overseas", so that a firm can tell its own clients which countries are involved and not just that some are. Our obligations to you are the same wherever information goes: we remain accountable for how an overseas recipient handles it.

Tax File Numbers, Medicare numbers, passport and licence numbers are removed before AI processing. Everything we send — documents and instructions alike — passes through an automated redaction step in Australia first, on every path, not only the main one. It is best-effort; see section 2 for the rare file it cannot check.

Email addresses are on that list too, by a different route. The AI is given a substitute rather than the real address, and the address is also removed from the source document — so, like the four above, it does not leave Australia. We added this in September 2026, when forwarded emails became something an accountant can drop straight onto a case.

Cryptocurrency wallet addresses, transaction hashes and exchange user IDs are removed too, where we can recognise them — which is not everywhere, so the promise above is not made about them. The AI is given a code — Wallet 1 — instead of the address, and what we recognise is also removed from the source document. Address formats with a built-in checksum, and Ethereum's, are recognised wherever we find them; the rest, and exchange user IDs, only beside a label or under a column heading in a spreadsheet or CSV file. One we miss is sent as it appears. A wallet address is a key to a public ledger, and a transaction hash leads straight back to one. We added this in September 2026.

Bank details are handled differently, and are not on that list. Section 2 sets out what happens to them: the AI is given a code rather than an account number or BSB — but the source document is sent as well, and they are not taken out of it.

Phone numbers and dates of birth are removed from the source document only beside a label, so the promise above is not made about them either. Since October 2026 a phone number with a label such as "Phone", "Mobile" or "Tel" on the same line, and a date of birth with a label such as "Date of birth", are taken out of the document as well as the text; a date of birth is replaced by its age band at 30 June. One printed with no label beside it can be missed and is sent as it appears. That limit is deliberate for phone numbers: taking one out means erasing part of the page, and the ten-digit patterns that find phone numbers also match invoice numbers and customer references, so the cost of a wrong guess would be a figure missing from a document the workpaper is built from.

The one exception used to be recognition. It is closed. To remove an identifier from a page we have to know where it is, and on a scanned page the only way to know is to read it — so a page our own Australian recognition could not read was sent to Anthropic as an image to be read. Since 10 August 2026 it is not. A file our redaction step cannot check is now handled as section 2 describes.

We are describing this rather than deleting the paragraph, for the reason the paragraph itself gave when the step still existed: a policy that quietly stops mentioning where an unreadable page goes reads as though it never went anywhere. It did. Now it doesn't.

What we found when we closed it is worth telling you, because it changes what the old wording was worth. That step was written to fire when a page could not be read — but in practice it fired whenever our recognition service failed to answer for any reason, including being briefly unavailable. It had never actually fired: across every document then held, not one had taken that path. So nothing was disclosed through it, and it would have applied to far more than unreadable pages the first time that service had an outage. We closed it before that happened.

Overseas legal process. Some of these providers are subject to the laws of the countries they operate in, including laws that can compel disclosure to a foreign government or law-enforcement agency. Contractual protections do not override that, and no provider can promise otherwise. We do not volunteer client information to any authority. Where we receive a request ourselves we require valid legal process, disclose no more than that process requires, and tell the affected firm unless we are prohibited from doing so.

We take reasonable steps to ensure these providers handle information consistently with the APPs, including through written data-protection terms and a contractual prohibition on using client information to train general AI models.

What we do not rely on. Your use of the platform is not, by itself, the consent a firm needs from its own clients. A registered tax practitioner has an obligation to their client to obtain permission before client information is disclosed to a third party — and for that purpose, we are the third party. That permission sits between the firm and its client; we are not a party to it and cannot obtain it on the firm's behalf. What we can do, and what this section is for, is describe accurately what the firm is asking permission for.

7A. BeforeMay Verify — identity checks

BeforeMay Verify is a separate product in which a firm checks who its client is — to meet its obligations to the Tax Practitioners Board, or its customer due diligence obligations under the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth). It works differently from the rest of BeforeMay, so it is described here on its own. Nothing in this section applies unless a firm sends a check.

Who does the check. The check is carried out by Didit (Didit Identity Spain, S.L., Barcelona, Spain), our identity-verification provider. The person being checked opens a link from their firm, agrees on our page to be checked that way, and is then handed to Didit's own page. What they provide there goes directly to Didit, not through BeforeMay.

What the person provides. A photo of an identity document (such as a driver licence or passport), a selfie and a short liveness capture. Didit reads the document and compares the face on it with the selfie. A face comparison is biometric information, which the Privacy Act treats as sensitive information, and we ask for the person's agreement before the check starts. For an anti-money-laundering check, Didit also screens the person against lists of politically exposed persons and sanctioned people, and re-screens them daily while the firm keeps the check under monitoring. Where a check includes it, the document's details are also confirmed with the Australian Government's Document Verification Service.

Where it is processed. Didit processes and stores verification data in the European Union (on Amazon Web Services). This is the one place in BeforeMay where a firm's client gives information straight to an overseas provider, and the one place where biometric information is handled. The redaction step described in section 7 does not apply here: the point of the check is for Didit to see the document, including its number. Didit acts on our instructions as our processor.

What BeforeMay keeps. Only the result: the person's name and date of birth as read from the document, the type of document, the issuing country and expiry date, the last three characters of the document number, whether each step passed and its score, the screening outcome, the date, and Didit's reference for the check. We do not keep the document photo, the selfie, the liveness capture, the full document number, the machine-readable line or the address on the document. The firm that sent the check sees that result; no other firm does.

What Didit keeps. The images and the detailed verification record stay with Didit, under our agreement with it, for the period set in our Didit account, and are deleted by Didit at the end of it. Didit does not keep a person's face template beyond the check unless we instruct it to, and we do not.

The firm's own obligations. A firm that uses Verify for anti-money-laundering purposes decides which checks to run and holds its own record-keeping obligations (section 8). BeforeMay provides the tool; the firm makes the customer due diligence decision.

7B. BeforeMay Return Fill (Chrome extension)

Return Fill is a Chrome extension that enters figures from a practice's delivered BeforeMay working paper into a draft return the accountant has open in LodgeiT or Xero Tax.

What it reads. Through the practice member's own signed-in BeforeMay session, it reads the practice's client list, its cases and their status, and the figures in each case's delivered working paper. On a LodgeiT or Xero Tax page it reads the return's identity (client name, return type and year). It reads a page's existing entries only to leave them untouched, and to check what it wrote after the page reloads. It never reads a tax file number, and it does not run on ATO Online services.

Where it goes. Figures go from BeforeMay into the tax platform page the accountant has open, and nowhere else. Return Fill sends nothing to any other party, uses no analytics and calls no AI model. Each fill and undo is recorded in the case's activity log in BeforeMay as a count (for example, 9 entries filled), not the figures themselves.

What it keeps. On the computer it keeps a reference that pairs the browser with the practice, and an optional screen PIN stored only as a salted verifier. A fill's progress and its Undo record are kept in the browser's session memory and are gone when Chrome closes. No client information is written to disk.

Sign-in. Return Fill has no password of its own. The accountant signs in on beforemay.com.au with the same two-step sign-in as Workpapers. Sign-in lasts at most 24 hours. Disconnect in the extension's Settings forgets the pairing and the PIN.

LodgeiT and Xero process the return under their own terms and privacy policies.

8. How long we keep it

We keep information for as long as the relevant firm's account or client is active, then under the rules below. A daily job enforces the automated items.

Some financial records may be retained longer where law or a firm's professional obligations require it.

AI provider retention is separate from our own storage. ZDR concerns the provider's handling of AI inputs and outputs; it does not remove your firm's source documents, client records or workpapers from BeforeMay.

• Fireworks AI. Its published policy provides ZDR by default for open-model inference: prompt and response content is not logged or written to persistent storage. A short-lived in-memory prompt cache may remain for several minutes; service metadata, such as token counts, is logged. We do not opt in to content logging or use its stored-conversation feature. This is the provider's published default, not a claim that all Fireworks features have the same retention.
• Anthropic. Its standard API policy deletes inputs and outputs within 30 days, subject to agreed arrangements, usage-policy enforcement and legal exceptions. ZDR is available for eligible services under an agreed arrangement; we do not make a blanket ZDR promise for Anthropic processing. The Files API is not eligible for ZDR: uploaded files persist until deleted. Our worker requests deletion of uploaded input files when a run ends, including failed runs. Deletion is best effort; failures are logged for follow-up, and files produced by the model are handled by a separate age-based cleanup. Copies in code-execution containers can remain for up to 30 days. Deleting an uploaded file does not immediately delete every processing copy.

We use commercial AI services under their no-training terms and do not opt in to sharing client content for general model training. No training and zero retention are different commitments. Deleting a firm's data from BeforeMay does not by itself delete a provider's copy; those copies follow the applicable provider retention and deletion rules above.

9. Security

The receipts storage bucket is private; we store object paths, not links, and issue short-lived signed URLs only after verifying firm membership or a valid portal token. Provider secrets and privileged keys live only server-side, never in the browser. Every privileged server function verifies the caller before acting, and security-relevant actions are logged. No system is perfectly secure, but we take reasonable steps to protect personal information from misuse, interference, loss, and unauthorised access.

10. If something goes wrong (data breaches)

If we become aware of unauthorised access to, unauthorised disclosure of, or loss of personal information held in the platform, we will:

• contain it and assess it promptly;
• notify the affected firm without undue delay, with what we know, what we do not yet know, and what we are doing — a firm cannot meet its own obligations to its clients on information we are sitting on; and
• where the incident is an eligible data breach likely to result in serious harm, notify the Office of the Australian Information Commissioner and, in co-ordination with the firm, the individuals affected.

The Notifiable Data Breaches scheme applies to us in respect of Tax File Number information regardless of our size, and we apply the same process to all client data rather than run two standards.

Where a breach occurs at one of our providers, we will pass on what that provider tells us. Report a suspected security or privacy incident to privacy@beforemay.com.au.

11. Your rights

Under the APPs you may ask to access or correct your personal information, or raise a privacy complaint.

• If you are a client of a firm, contact that firm first — they control your records in the platform, and we will assist them.
• Firm users can contact us directly at privacy@beforemay.com.au.

We will acknowledge a request or complaint within 7 days and respond substantively within 30 days. If you are not satisfied with how we handle a complaint, you can contact the Office of the Australian Information Commissioner (OAIC) at oaic.gov.au.

12. Children

The platform is a professional tool for accounting firms and is not directed to children. We do not knowingly collect children's information except where it appears within a firm's tax records, in which case it is handled as the firm's client data.

13. If you are a registered tax practitioner

This section is for our customers, not their clients. It is information, not legal advice — get your own.

The Tax Practitioners Board issued TPB(GS) 55/2026, The use of Artificial Intelligence and the Code of Professional Conduct, on 22 July 2026. Two points in it bear directly on using this platform.

Client permission. Code item 6 says that unless you have a legal duty to do so, you must not disclose information relating to a client's affairs to a third party without the client's permission. The guidance treats any entity other than you and your client as a third party, and says that entering client information into AI models and tools can be such a disclosure, "depending on how these tools are configured and used" (para 23). We are a third party. Sections 2 and 5 to 7 describe our configuration exactly — what is stripped before anything leaves Australia, what is not, and the one case where a page does leave to be read. You need your client's permission before you put their information into this platform.

The guidance lists the forms that permission can take (para 24): a signed letter of engagement, a signed consent, another communication such as a relevant "fact find" and consent, or a general authority consenting to disclosure to third parties. Many standard engagement letters already contain such an authority. It also recommends — as good practice rather than a requirement — that you tell the client to whom and where the disclosure will be made, where data will be stored, and whether AI tools may be used. Sections 6 and 7 are written so you can answer those four questions, and we publish a clause you may adapt for your own engagement letters.

Where the information includes a TFN, the guidance notes at paragraph 26 that additional obligations under the Privacy (Tax File Number) Rule 2015 apply. We strip TFNs before a document leaves the country (section 2), but that reduces the exposure — it does not move the obligation off you.

Your review is your own. The guidance is explicit that you remain responsible for the accuracy of the work, must apply your own professional judgement, and must not treat AI output as a substitute for your own analysis. It also says the steps you take to verify and review AI-generated content should be documented, to support ss 30 and 40 of the Tax Agent Services (Code of Professional Conduct) Determination 2024. The platform records the AI's findings, your responses to them, who changed what and when, and each version of the workpaper, and that record is exportable — but the review itself is yours.

14. Changes

We may update this policy. We will change the effective date above and, for material changes, notify firms through the platform or by email.

Changes to the sub-processor list in section 6 are material changes. Adding a provider that will handle client data, or moving one to a different country, is notified to firms before it takes effect, so a firm has the chance to review it against what it has told its own clients.

Outblock Pty Ltd · ABN 94 655 314 051 · Oatley NSW 2223, Australia · privacy@beforemay.com.au