Mention Ezyiah to an experienced accountant and one question almost always follows: is this replacing bank rules, or doing something else? It is a fair question. Bank rules have been part of the Xero, MYOB and QuickBooks workflow for years, and teams have invested real time building them, refining them, and teaching juniors to rely on them. The worry is not whether Ezyiah works. It is whether it introduces overlap and extra steps into a system that already feels fragile during BAS. The honest answer is that Ezyiah does not replace bank rules at all. It does the thing bank rules were never able to do.
What bank rules are good at, and where they break
Bank rules are built to automate repetition. When the same merchant appears with the same structure, the rule fires consistently and saves time, and for stable, predictable transactions that works genuinely well. It reduces manual coding, speeds up processing, and lets junior staff move faster on clean data. What a rule cannot do is reason. It does not understand context, it does not ask why a transaction looks different this quarter, and it does not notice when a familiar merchant quietly changes its pricing, its description format, or its GST treatment. It applies the logic exactly as written, even when the data underneath has shifted.
The problem is that real accounting data is rarely stable. Descriptions change, amounts vary, suppliers restructure, new payment processors appear, CSV exports truncate fields, and feeds fail and re-sync. When that happens, a rule either stops firing or fires incorrectly, and the dangerous outcome is the second one. Not an obvious error, but a silent misclassification that looks perfectly consistent and is quietly wrong. By the time reconciliation and BAS review begin, that assumption is already embedded in the ledger, and correcting it means reversing and reclassifying entries after the fact. At scale, that is exactly what partners dislike, because every late correction adds audit risk, review time and uncertainty right before lodgement. This is why many firms quietly limit how hard they lean on bank rules for GST-sensitive categories. The hesitation was never about automation. It is about trust.
What Ezyiah does differently, and how the two work together
Ezyiah does not compete with bank rules, it covers their blind spot. Instead of applying static logic inside the ledger, it reviews transactions before they ever reach it, checking patterns, amounts, descriptions and context in bulk, so an accountant can validate assumptions, catch anomalies and confirm GST treatment before any of it becomes part of the source of truth. The rules still exist and still do their job. They simply operate on data that has already been cleaned and verified, which is the state they were always assumed to be working in and rarely are.
In practice firms run both, without overlap, because they do different jobs. Ezyiah works upstream to review and verify transactions in bulk, and once that data is trusted it flows into Xero, MYOB or QuickBooks, where bank rules keep handling the stable, low-risk repetition they are good at. Bank rules handle repetition, Ezyiah handles uncertainty, and keeping those two separate is the whole point. It means automation stays where it works best and judgement stays where it is safest, instead of asking a static rule to make a call it was never designed to make.
Why this makes BAS easier, not harder
During BAS, time pressure amplifies everything. The cost of a silent mistake is higher and the tolerance for rework is lower, so the misfired rule that looked harmless in March becomes an expensive problem in the final week. By resolving the ambiguity before data reaches the ledger, a firm removes most of the late-stage corrections and the partner-review stress that comes with them. There is less to reverse, less to explain, and fewer uncomfortable conversations about why something was coded the way it was.
So the extra step does not make BAS harder, it makes it calmer and more predictable, and crucially more defensible. Ezyiah does not replace bank rules, it protects them, by making sure they only ever run on data that has already been reviewed. Separate the review from the reporting, and a firm gets to keep its automation exactly where it earns its place while keeping human judgement in front of everything that actually carries risk.
