Nine hundred statement lines, and the only place the match exists is in one person's head
The bank tells you money moved. The ledger tells you what was owed. Neither document says which payment settled which invoice, and that sentence is the whole job. Most lines are obvious, one payment, one invoice, same partner, same amount, and they are obvious again next month, and the month after that. The ones that are not obvious are a customer paying three invoices in one transfer, a payment short by the bank's own fee, a transfer between your own accounts that looks exactly like revenue. Those need judgement. The problem is that they arrive interleaved with the eight hundred that do not, and the person who can tell them apart has to read every line to find them.
Matches are proposed only -- the agent logs a finding note in Odoo. Nothing reconciles or posts automatically.
What you get with account reconciliation
Most of your statement clears itself. Odoo comes with a matching engine already built in, and out of the box it handles the cases that come back every month, an invoice and its payment that agree exactly, a partial payment against a larger invoice, a transfer between two of your own accounts, a line that's short only by a bank fee. Those reconcile without anyone reading them. What's left is a short queue: the handful of lines that genuinely need a person to decide what they are. That queue is the job. Everything above it is work the software already took off the desk.
Where account reconciliation comes from
It's already in Odoo, nothing to add, no upgrade tier to reach, no extra fee per user, and the system runs on infrastructure you own. NetSuite bills this as a module and a per-seat renewal; in Odoo it is already included, and that difference is the product. (Statement files are loaded rather than auto-fetched, see the FAQ below on how the data gets in.)
What the agent adds to account reconciliation
Your team stops reading the statement line by line to find the few that matter. Give it a start date and the agent reads every unmatched line against your open invoices, then hands back only the ones worth a person's attention, each with a candidate match, a confidence score, and a plain sentence for why it flagged them. Your accountant approves or rejects the shortlist, and each approved match is logged against its invoice, ready to complete. The agent finds the match and hands it over; the person still makes it. It flags, it never moves money on its own.
This is a real, published workflow, and it's advisory by design: it raises the match and waits for a person. An agent that flags and an agent that posts are different products, this is the flagging one, on purpose. Nothing here describes a result at a customer; Del AI has completed no migrations yet.
What is account reconciliation?
Account reconciliation is the check that a balance in the general ledger agrees with an independent record of the same thing, and the work of explaining any difference. A bank account is reconciled against the bank's own statement, a receivables control account against the list of open customer invoices behind it, a credit-card account against the card provider's file. The point is not the total, which the ledger already computes. It is provenance: a balance that ties to an outside record is evidence, and a balance that only ties to itself is an assertion. A reconciliation is finished when every line on one side is linked to a line on the other or has a named reason for standing alone, which is why the hard part is never the arithmetic, it is the handful of lines that need somebody to decide what they are. What does a bank reconciliation rules engine actually match, and what does it leave behind? A rules engine matches the cases that can be stated as a rule. The common ones are a statement line whose partner and amount agree exactly with one open invoice, a line that is short by a known bank charge, a line that is a transfer between two accounts you own, and a partial settlement of a larger invoice. Each of those can be written as a condition and applied unattended, so a well-seeded engine clears most of a statement without anyone reading it. What it leaves behind is everything whose meaning depends on context the ledger does not hold: one payment covering several invoices in a proportion nobody wrote down, a deduction the customer took for a disputed line, a receipt from a party whose name in the banking system is not the name on the invoice. Those are not edge cases in the sense of being rare, they are the reason the reconciliation still needs a person, and the useful measure of an engine is not how many lines it clears but how small and how genuinely ambiguous the remainder is.
What should an AI agent do when it thinks it has found a matching payment?
It should propose the match and let a person accept it, rather than post it and report afterwards. The distinction sounds procedural and is not: proposing and posting are different products. A proposal that turns out to be wrong costs a rejected suggestion. A posting that turns out to be wrong has already changed a customer's balance, and unwinding it means reversing a reconciliation, restating a receivables figure someone may have reported on, and explaining to that customer why they were chased for an invoice they had paid. A match is a judgement made on thin evidence, a name, a number and a date, and the agent that shows its candidate with the reason it believes it is asking the right question, while the agent that writes the entry has answered it on the reader's behalf. Oracle describes the other design on NetSuite's own reconciliation page: "Fully automate time-consuming, repetitive reconciliations, such as zero-balance, low-value, or low-risk reconciliations, based on rules you set." That is a coherent position, and it depends entirely on the rules being right about what is low-risk. The safer default is that the ledger moves when a person says so.
Do bank statements import automatically into Odoo Community?
No. Odoo Community has no live bank feed and no statement-file importer in the stock image: there is no online-synchronisation module and no OFX, QIF or CAMT reader, so statement lines are loaded rather than fetched. This matters when you are planning a close, because it separates two things vendors usually sell as one. Getting the data in is a file operation, and it is a solved and boring one. Deciding what the data means, which payment settled which invoice, is the reconciliation, and that is where the matching rules and the reconciliation objects live in Community, fully and without an add-on. Ask any vendor which of the two they are describing when they say automated bank reconciliation, because a product that only imports the statement has not reconciled anything.