| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Invoicing (account)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 3345 |
| Technical Name |
eh_account_ai_agent |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
| Availability |
Odoo Online
Odoo.sh
On Premise
|
| Odoo Apps Dependencies |
•
Invoicing (account)
• Discuss (mail) |
| Community Apps Dependencies | Show |
| Lines of code | 3345 |
| Technical Name |
eh_account_ai_agent |
| License | LGPL-3 |
| Website | https://www.erpheritage.com.au/ |
AI Agent Layer
Three accounting AI capabilities. Working defaults today; LLM upgrade when you want it.
Overview
What this module does, in one read.
Anomaly detection on journal entries, variance commentary on close-period budgets, next-best-action on collections cases. Each capability ships a deterministic default that runs without any LLM dependency. A pluggable LLM hook activates when a provider is configured. A misconfigured provider degrades silently to the deterministic output, so the suite never breaks on a missing API key.
Day in the life
Month-end close. 4,000 posted entries to review by tomorrow.
The close run kicks off Wednesday afternoon. The anomaly detector scans all 4,000 posted entries against four rules and flags 47 candidates: 12 round-number outliers above 3x the period median, 8 weekend posts, 6 just-under-threshold structuring patterns, 21 reversal-pair candidates. The reviewer drills into the 47 instead of all 4,000, which saves five hours. The variance commenter then produces a one-paragraph headline for the budget pack: 'Period total overran by 12.2% driven by Salaries +10% and Marketing +47%.' The collections engine flags 8 cases that need tomorrow's manager call (broken promises, day-95 demand letters, day-180 write-off candidates). All three run on deterministic rules with no LLM bill.
Capabilities
8 things this module gives you, with no padding.
Round-number anomaly detector
Flags entries that are exact thousand multiples and exceed 3x the period median. Catches the placeholder entries auditors investigate first.
Weekend-post detector
Surfaces journal entries dated Saturday or Sunday so reviewers can confirm out-of-hours posts match policy.
Just-under-threshold detector
Flags amounts within 5% below the configured approval threshold. Standard structuring-detection control auditors expect.
Reversal-pair detector
Catches same-user wash entries: debit + credit on the same accounts on the same day for the same amount, posted by the same user.
Variance commentary
Plain-English template: 'Period overran by X% driven by largest variances on lines A, B, C.' LLM upgrade swaps in a natural-language paragraph.
Collections next-action ladder
Eight-branch dunning ladder: broken_promise to escalate, 90+ days to demand letter, 120+ days with letter to agency referral, 180+ to consider write-off.
Provider registry
Same pattern as the bank-feed and AP-extractor stubs: Claude / OpenAI / local stubs out of the box; real adapters in paid extension modules under the same key.
LLM-failure safe
Capability calls catch ProviderError and fall back to the deterministic output. A bad LLM key degrades gracefully, never breaks the call site.
Compared
How this module stacks up.
Workflow
Configure once. Operate. Audit.
Pick a provider
Default 'manual' uses deterministic capabilities only. Set company.eh_ai_provider_key to claude/openai/local for LLM augmentation.
Capability call sites
Anomaly + variance + collections capabilities import their tools and call the deterministic helper. LLM augmentation is opt-in.
Result rendering
Findings, comments, suggestions render in their respective views: close runs, budget reports, collections cases.
Audit + override
Every capability output is logged. Operators can override the suggestion or re-run with different parameters.
Why Heritage
Where this leads, where it matches, what we are honest about.
- Deterministic rules ship working today, no API key required.
- Provider registry mirrors the bank-feed and AP-extractor patterns; uniform across the suite.
- LLM-failure safety: a bad provider degrades silently to deterministic output.
- Standard accounting AI scope: anomaly, variance, collections.
- Same testing rigor as the rest of the suite.
- Stub-then-paid-extension pattern matches Plaid / Basiq / Claude / OpenAI elsewhere in the suite.
- Deterministic anomaly rules are conservative. A real auditor still needs to spot-check.
- LLM providers ship as stubs that refuse live calls; install the paid extension module for real chat completion.
- Collections ladder is rule-based today. Production teams may want to override per case-segment.
The full ERP Heritage Accounting Suite (26 modules)
Engineering
Ten engineering rules we hold ourselves to.
No silent fallbacks.Missing config, missing accounts, malformed input each surface explicit messages naming the bad field.
Tests cover the bug, not just the feature.Every defect found in review has a regression test attached to the fix, kept in the repository.
Plain Python where possible.Algorithms that do not need the ORM live under tools/ with unit tests that run without Odoo.
Atomic counters via SQL.Concurrent counters use UPDATE col = col + 1, never read-modify-write loops.
Per-record savepoints in cron loops.A single bad record never freezes the batch; failing rows are recorded, the rest of the batch keeps moving.
Schema-first XML output.PAIN.001 / PAIN.008 / UBL 2.1 generators target the published namespace; tests parse output back and assert structure.
ValidationError versus UserError.Constraint failures raise ValidationError; action failures raise UserError with a remedy.
Privilege groups, not direct upstream references.ACL CSVs reference suite-specific groups; the post-migration script promotes upstream-only users.
Append-only audit logs.Approval log, override log, reconciliation audit, mandate amendment log all override write and unlink at the model level.
Originality from public spec.Every standard implementation is built from the published technical specification, not from another vendor codebase.
The standard we hold: every shipped capability is original code from a public technical specification, with regression tests, with a documented engineering rule for the invariant the code preserves, and with no vendor names in code or user-facing docs. From the suite contributing process
Frequently asked questions
Honest answers to the questions a buyer asks.
Does this require an LLM provider?
No. Every capability has a deterministic default that runs without network access, API keys, or paid services. The LLM hook is opt-in.
Which LLM providers are supported?
Stubs for Claude, OpenAI, and local OpenAI-compatible endpoints (Ollama, vLLM, llama.cpp) ship out of the box. Real implementations install as separate extension modules under the same registered key.
What happens if the LLM provider fails?
The capability silently falls back to the deterministic default. The failure is logged on the underlying record so the operator can investigate without breaking the call site.
Is my data sent to a provider?
Only if you configure a non-manual provider. The deterministic defaults are pure local computation; nothing leaves your server unless you opt into an LLM hook.
Does this run on Odoo 19 Community?
Yes. Every module is built and tested against Odoo 19 Community. No Enterprise dependency anywhere in the stack.
What is the licence?
LGPL-3. Source available, modify and redistribute, with the LGPL terms on derivative works.
Will this conflict with another accounting addon I already use?
All models, fields, and security groups are namespaced under eh_. Conflicts with other suites are unlikely, and we test against the stock OCA + Odoo Enterprise modules.
Are the engineering principles documented?
Yes. The Engineering rules section above lists the ten invariants we hold across the suite. Every module references these rules in its CHANGELOG entry.
Is there a test suite?
Yes. Each module ships unit + integration tests; the test suite runs against Odoo 19 Community with no Enterprise dependency. Test counts are documented in CHANGELOG.
How do I get support?
Reach out via info@erpheritage.com.au or +61 469 095 910 (also www.erpheritage.com.au). Testing, deployment, and customisation work is invoiced via ERP Heritage.
Built by ERP Heritage
ERP Heritage builds accounting suite engineering for the Odoo Community ecosystem. Originality matters: every module is built from the public technical specification, with regression tests, plain Python where possible, and no vendor names in code or user-facing docs.
Built in Australia. Distributed under LGPL-3.
Talk to ERP Heritage about Odoo implementation, customisation, training, or support.
End-to-end engagement across the Odoo platform: implementation, customisation, reimplementation, functional and technical training, ongoing support, integration planning, and scoped extensions. One team, one response within a business day.
AI Agent Layer, drop-in for Odoo 19 Community.
No Enterprise dependency. No vendor lock-in. Original work under LGPL-3.
Please log in to comment on this module