Bank reconciliation used to mean a bookkeeper working through a statement line by line once a month, matching each deposit and withdrawal against the books by hand. In a modern property accounting system, most of that matching is already finished by the time anyone sits down to close. Here is how the process actually works, and where AI reasoning fits into it alongside the person who still has to approve every entry.
Nightly bank feeds instead of a monthly statement
The first change is timing. Rather than waiting for a monthly bank statement to reconcile against, live bank feeds sync nightly, together with payout and settlement data. That means the books are working against current activity every day, not a static snapshot that is already weeks old by the time reconciliation starts. For a finance lead managing several properties, this removes the single biggest bottleneck in a traditional close: waiting for statements to land before any matching work can even begin.
Three passes of matching, in order
Matching a bank line to the right entry in the books is not one operation, it is three, run in a specific order so that the most certain answer always wins.
The first pass is deterministic rules that the customer defines. These are rules the property or the management company sets up themselves, for example matching a specific vendor's recurring payment automatically. This is the only pass that is allowed to match a transaction without a human anywhere in the loop, because the rule itself was authored and approved by a person in advance.
The second pass is algorithmic matching on amount and date. For lines the customer defined rules did not catch, the system compares transaction amounts and dates against open items in the books and resolves the matches that are unambiguous on those two facts alone.
The third pass is HERO AI reasoning on whatever is left. Once deterministic rules and algorithmic matching have done what they can, the remaining lines, the ones with no obvious counterpart, no clean amount and date match, go to HERO for reasoning. This is the layer built for the genuinely ambiguous cases: a bank line that does not map cleanly to any existing record.
What HERO does with a truly unmatched line
The clearest example of that third pass is a bank line for a vendor that does not exist yet in the books. Rather than leaving that line sitting unresolved for a person to research from scratch, HERO can draft a new vendor record and a reconciled expense entry from that single unmatched bank line. The draft is exactly that, a draft. A person still reviews and confirms it before it becomes part of the books. HERO is not posting anything on its own, it is doing the research and assembly work that used to take a bookkeeper real time to track down, and handing over a ready to confirm proposal instead of a blank line and a question mark.
Books arriving up to 90 percent pre reconciled
The result of running all three passes together, deterministic rules, algorithmic matching, and AI reasoning, is that books arrive pre reconciled at up to 90 percent before close even starts. That number describes how much of the reconciliation work is already resolved by the time a person opens the account to review it, not a guarantee that applies to every account in every month. The specific mix of customer defined rules, clean amount and date matches, and lines requiring AI reasoning will vary by property, by how many rules have been set up, and by how routine that month's activity was.
What that pre reconciled state changes in practice is where a finance lead's attention goes. Instead of starting from a blank statement and working every line, the review starts from a short list of exceptions, the lines that genuinely needed judgment rather than a rule or a clean match. That is a materially different task, and it is the difference between reconciliation eating a full day and reconciliation eating an hour of focused review.
Month end close, per bank account
Reconciliation feeds directly into month end close, and close itself is structured differently once this matching pipeline is in place. Rather than closing an entire property's books all at once, close happens per bank account. An operating account that has finished matching does not have to wait on a trust account that is still resolving a handful of lines, so the accounts that are ready can close on their own timeline instead of holding up the rest of the property.
For each account, the AI proposes balanced adjusting entries to explain whatever statement differences remain after matching, the small variances that are not a missing transaction but a timing difference, a bank fee, or a similar reconciling item. The AI cannot post these adjusting entries itself. Every proposal sits and waits for a person to accept it as written or modify it before anything is recorded in the ledger. That boundary is not a temporary limitation, it is how the system is built: AI suggests, people approve, on every entry, every time, with no exception for the entries the AI itself proposes.
What stays exactly the same
None of this changes the underlying discipline of the ledger. Closed periods still lock and block further posting once a person closes them, and reopening one leaves a full audit timeline of who did what and when. Trust accounting rules still apply without exception: every ledger line carries its fund tag, deposits stay liabilities until resolved, and corrections still post forward rather than editing history, regardless of whether the original entry came from a customer defined rule, an algorithmic match, or a HERO proposal a person accepted. An accountant reviewing the books after close can trust the same audit trail they always could, because the controls around what gets posted have not moved, only the amount of manual matching work required to get there.
What this looks like across a portfolio
The value of this matching pipeline compounds as the number of properties grows. A single building's bank account is manageable by hand. A portfolio of dozens of buildings, each with its own operating and trust accounts, each generating its own nightly feed of deposits, vendor payments, and payouts, is a very different scale of problem. Deterministic rules that a customer defines for one property's recurring vendor payments do not automatically apply to another, so each property builds its own rule set over time, and the algorithmic and AI reasoning passes pick up whatever those rules do not already resolve.
That per property structure matters for accuracy as much as for speed. A rule that makes sense for one building's utility provider might not apply cleanly to another building using a different vendor, so keeping matching scoped to each property's own accounts and its own defined rules avoids false matches that a one size fits all approach could introduce. The tradeoff is that a portfolio benefits from AI reasoning being consistently available on every account, since it is picking up the same category of ambiguous line whether the portfolio has three properties or thirty.
Why the person still has to decide
It is worth being direct about what HERO does and does not do in this pipeline, because the distinction is the entire point. HERO reasons about unmatched lines and proposes matches, new vendor records, and reconciled expenses. It proposes adjusting entries at month end. It does not post any of that to the ledger. A person confirms the vendor draft, a person accepts or edits the adjusting entry, a person closes the period. The only step in this entire process that can move money in the books without a person actively looking at that specific line is a rule the customer wrote themselves in advance, and even that rule had to be approved and configured by a person before it could run automatically.
This is not a limitation to be lifted in some future release, it is the design. An accounting system where AI can post directly to the ledger without a reviewable proposal is not a system an auditor, a board, or a finance lead should trust with money that belongs to other people. Keeping the AI's role to drafting and proposing, and the person's role to accepting, editing, or rejecting, is what makes the speed gains from automated matching compatible with the audit trail the books still need to carry.
What this means for an accounting team
For an accountant or a finance lead running close across several properties, the practical shift is where hours go. Time that used to go into line by line matching goes instead into reviewing the handful of exceptions that genuinely needed a decision, confirming HERO drafted vendor and expense entries, and accepting or adjusting the AI proposed entries that explain what is left after matching. The ledger itself, the fund tagging, the immutable history, the locked closed periods, has not changed. What has changed is how much of the mechanical matching work is already done before a person opens the account, and how much closer to finished the books already are by the time month end close actually begins.
URBI Accounting is currently in Beta. Accountants and finance leads who want to see this reconciliation and close process running against their own portfolio can sign up for the Beta program.
