Security
You are the one who answers to your clients if their financials end up somewhere they should not be, so you should not have to take a vendor's word for anything. This page is the whole picture: what protects the data, who can reach it, and who else can touch it.
Most security pages say "bank grade encryption" and stop there, which tells you nothing you could check. This one names the actual control, gives it a reference you can quote back at us, and sets out which supplier can see what. If any of it is not specific enough to verify, ask and we will show you.
Records are stored in Sydney, processed in Sydney, and the email about them is sent from Sydney. The one exception is the masked document we send out for drafting, which is set out below.
In transit and at rest, with the credentials for your Xero and BGL connections sealed again on top of that.
Which organisation a request belongs to is decided by a signed credential, not by anything a browser can edit.
Permissions run down to individual fields. If someone is not allowed to read a field, the server leaves it out of the response instead of the screen hiding it.
The trail is append-only at the database level, so our own software has no way to edit or erase it.
The AI maintains the sorting rules and writes the drafts. Your team are the ones who send.
Your clients' financials stay in Australia. The two places anything crosses a border are written down here instead of being left out.
The database holding every client record, the servers that process them, and the system that sends your clients their email all run in the same Sydney region. Nothing is stored outside it and nothing is replicated to a second country.
Sorting a document and drafting the email means sending that document to an AI model provider, which for us is currently Anthropic, running on global infrastructure rather than from Australia. It is masked before it goes: tax file numbers, payment reference numbers and EFT codes are stripped out first, and the provider does not keep it after the request or train on it. This is the only point in the product where anything out of a client document is handled outside the country. That is what the masking below is for.
The site sits behind Cloudflare. A browser connects to whichever Cloudflare location is nearest, and the request reaches us from there. For someone in an Australian office that is an Australian city. Nothing is stored at that location and the connection stays encrypted the whole way, but a partner working overseas has their request pass through a machine overseas.
The servers running the product refuse all inbound traffic except through the protections in front of them. There is no direct path to a server that skips what is in front of it.
Encrypted in transit and at rest, with a second layer over anything that would be useful to someone holding a stolen copy of the database.
Browser to network is encrypted, and network to our servers is a second encrypted connection, with our certificates checked on that hop instead of taken on trust. None of our servers accept an unencrypted connection at all, so there is nothing to fall back to.
Everything stored on disk is encrypted with AES-256 at the storage layer.
When you connect Xero or BGL, the access tokens that come back are encrypted again before they are written down, under a key that lives only on the servers themselves and never in the database. Each one is tied to the record that owns it, so a stolen token will not open anywhere else.
Passwords are hashed and never stored, logged or shown anywhere, including to us. Session cookies cannot be read by page scripts or carried to another site, and the permission tokens inside them last minutes rather than days.
Three separate groups can reach the product: your team, your clients, and us. Each one gets its own door, and the doors do not open onto each other.
You set read, write or nothing per area of the product, and sensitive fields can carry a tighter rule of their own. The check happens in one place, shared by every read, every write and every live update, so there is no second copy of the rule to drift. A field someone is not allowed to read never reaches their browser.
The client portal is a separate application on its own domain, not a view of your workspace with bits hidden. A client reaches it through a signed link that you can revoke on the spot, and every request it makes gets checked again instead of being trusted for the life of the link.
Every account signs in with a password and a one-time code from an authenticator app. Failed attempts are capped well below the rate anyone would need to guess at one, and that cap is shared across our servers, so moving to a different one does not reset it.
Support access works one way: a short-lived session carrying the support person's real identity, granted for a single job. Every action taken inside your organisation is recorded against them in your audit trail, never against one of your team, so you can always tell our work from your own.
One organisation seeing another organisation's clients would be the worst thing this product could do. It gets more attention than anything else in the build.
Which organisation a request acts on is read from a signed credential that the browser cannot forge or edit, and your membership is checked against the database again whenever it is reissued. Changing an id in a web address does not move anyone sideways into your records, because the address is not what decides.
Every query that touches organisation data is generated from one declaration per record type, so the separation is applied in a single place instead of being written by hand in hundreds. Underneath that, the database enforces the same boundary itself, which means a mistake in our code still runs into a wall our code does not control.
You carry professional obligations about client records, so the trail is built to hold up when somebody asks about it months later.
The product connects to the database with permission to add audit entries and read them, and no permission to change or remove one. The database enforces that, not our own code, so neither a bug nor an attacker inside the software could quietly rewrite history.
Each entry records who acted, what they did, what they touched and when. Every request also carries an id that comes back to the browser, so an audit entry, a server log line and something a team member saw on screen can be lined up afterwards.
Every e-signature keeps the signer, their IP address, their browser and the time it happened, held separately from the document itself. If the document is ever disputed, the evidence for the signature does not depend on the file it was attached to.
Audit records are kept for the life of your account and are never rolled up, sampled or aged out to save space. If you leave, the export takes them with you. We are not going to delete records you still have your own obligations over.
Sorting ATO correspondence is the reason this product exists, and it is the part organisations ask about hardest. These are the rules it works under.
TFNs, payment reference numbers and EFT codes are stripped out of a document before its contents go anywhere near a model. If the masking fails, the document stops and raises an alert for us instead of going through anyway.
Document type is matched against a maintained list of patterns, not guessed. An AI keeps that list current as the ATO changes its forms, but a person reviews every pattern before it goes in, so we can explain what happened to any individual file.
The pipeline sorts the file and drafts the email. It does not send, and it does not make a change that cannot be taken back. Anything it is unsure about waits in a review queue for one of your team instead of being guessed at.
Whichever model provider we are using, the terms are the same: our content is not kept past the request that used it, and it is never used to train anything. We currently use Anthropic, and they are named in the supplier table below, so a change of provider is a change you can see.
Your records are yours while you are with us, and they are still yours on the way out. That second half is the part most software stays quiet about.
Your client records are yours. They are not sold, not shared with anyone outside the suppliers listed further down this page, and not used to build anything we sell to someone else.
A full export of your organisation's records in an open format, on demand, from inside the product. You do not have to ask us for it or wait on a support queue.
When you close an account your records are deleted within the window set out in your contract. We do not hold onto them indefinitely. The only things that survive are entries we are legally required to hold onto, and we tell you what they are.
The full list of suppliers who could come into contact with your data. Nobody else is on it, and this page changes if that ever stops being true.
| Supplier | What they do | Where | What they could see |
|---|---|---|---|
| Amazon Web Services | The servers the product runs on, and the email it sends | Sydney (ap-southeast-2) | Records in memory while a request is handled, and the contents of the email we send |
| Supabase | The managed database, itself running on AWS | Sydney (ap-southeast-2) | Every stored client record |
| Anthropic | Our current AI model provider, reading masked ATO correspondence to draft the email | Global | Masked document contents, with the identifiers stripped out first |
| Cloudflare | Network, encryption and hosting for the front end | Global network | Traffic in transit, nothing stored |
| Stripe | Collecting payments from your clients | Global, with an Australian entity | Billing details. Card numbers never reach us |
| Xero, BGL, Microsoft, Google Only if you connect it | Platforms you connect for import, storage and email | Set by that platform | Only what you connect them to, when you connect it |
We have a written plan for this rather than something we would work out on the day. If an incident ever touched your data you would hear it from us directly and in writing, with what we know and which of your clients are involved. You would hear it while we were still working through it, because you carry notification duties of your own under the Privacy Act and you cannot meet them on information we are sitting on.
Version 1.0 · reviewed 3 August 2026 · this page is versioned, and older statements stay quotable. If something here changes, the version and date change with it.