GL account
From your own posting history for that vendor, that line description, and that amount range — not from a generic mapping of merchant categories to accounts.
AI capability
There is no universally correct account for a $4,180 hosting invoice. The right answer depends on how your company has coded that vendor for three years, which department consumes it, and whether your controller treats hosting as cost of revenue. Classification is a company-specific problem wearing a general-purpose costume.
What it does
From your own posting history for that vendor, that line description, and that amount range — not from a generic mapping of merchant categories to accounts.
Department, location, entity, project, and class. Coding an account correctly and leaving the department blank produces a report that silently excludes the transaction.
One invoice spanning three departments or two projects, split on the pattern you have used before or on an allocation rule you configured.
Feed transactions classified with the same logic, matched against receipts and expense reports where they exist.
Below threshold goes to a person rather than posting a plausible guess. The threshold is yours to set and differs by account sensitivity.
Every re-code your team makes becomes a labelled example specific to you, which is why the curve climbs rather than arriving flat.
Consumer and small-business tools classify by merchant category: this is a software vendor, software goes to account 6500. That works when the chart of accounts is standardised and the stakes are low.
In a mid-market business neither holds. Two companies with identical vendors will code them differently and both be right — one treats hosting as cost of revenue because it is consumed delivering the product, the other treats it as operating expense because it runs internal systems. A classifier that does not learn from your postings will be confidently wrong for one of them.
Account-level coding is the easy part and the part everyone measures. The department, location, and project on the line are harder and more consequential, because an account coded correctly with a blank department produces a department P&L that silently excludes the transaction.
We report accuracy separately for account and for each dimension, because a blended figure hides exactly the weakness that damages reporting. Dimensional accuracy starts lower and climbs more slowly, and saying so is more useful than an averaged number that looks better.
When the agent cannot classify confidently, it is frequently not because the document is unclear — it is because your own history is inconsistent. The same vendor coded to three accounts across two years, usually because different people coded it at different times.
Surfacing that is worth more than the automation. It is a chart-of-accounts conversation that has been quietly degrading your reporting, and most customers resolve a dozen of these in the first month.
Limits
Every capability page on this site carries one of these, because a feature described without its boundaries is a claim rather than a description.
If your team has coded the same vendor three different ways over two years, there is no correct answer to learn. It flags the inconsistency rather than picking one, which is more useful.
A vendor supplying something you have never bought has no history to learn from. The first few go to a human, and that is the system working.
Whether hosting belongs in cost of revenue or operating expense is an accounting decision with real consequences for reported gross margin. You decide once; it applies your decision.
Questions
A month of posted transactions is enough to measure agreement at the account and dimension level.