Inter-Company Rules
Post a sale in one company and the matching purchase bill is built in the sister company, with a review queue that catches every pair that did not mirror cleanly.
Why this module
Inter-Company Rules
One post, both sides
A posted sale invoice builds the matching purchase bill in the sister company, and a vendor bill mirrors back to a customer invoice. Refunds mirror the same way. The mirror lands draft for review or auto-posts, per destination company config.
Duplicate-proof by construction
Each mirror stores an origin pointer and a database-level unique(origin, company) constraint makes re-posting and concurrent posts idempotent. Two simultaneous posts cannot both create a twin bill, the constraint closes the race at the database.
Nothing fails silently
A stored lifecycle state with list badges, search filters and a dedicated review action means a supervisor sees only the pairs needing attention: no mirror, mirror draft, or an amount mismatch above one cent once both sides are posted.
Day in the life
A group accountant invoices a sister company and moves on.
She posts a customer invoice from the trading company to a related entity. The partner names the company it represents, so the module immediately builds the matching vendor bill in that entity, in the same currency and with the same per-line amounts, and links both invoices with a chatter note pointing at each other. The bill lands in draft for the receiving accountant to review. Later a colleague edits a mirror line by hand; the next time both sides settle, the divergence above one cent flips the pair to Amount mismatch and it surfaces in the Inter-company review action. One destination journal was left unset on a third company, so that mirror could not build, but the source still posted and the reason is sitting in its chatter, flagged No mirror in the same review queue. Nothing was double-entered, and nothing went missing quietly.
Edge cases
The cases most modules quietly ignore.
In the shipped code today, each one a place where a cheaper module silently does the wrong thing.
Two concurrent posts cannot both create a mirror. A database-level unique(origin, company) constraint closes the race that a search-before-create guard alone would lose, and a regression test exercises exactly that duplicate path.
If any step of the mirror build fails, the source invoice still posts, the explicit reason is written to its chatter, and the state flips to No mirror so the unmirrored pair surfaces in the review queue instead of blocking the close.
Once both legs are posted, a divergence above one cent (a manual edit, a missing line, FX drift) flips the pair to Amount mismatch for human review rather than being ignored.
The mirror line uses the destination company's product account first, then the configured fallback account, and if neither exists it raises an error naming the exact field to fix. No NULL account ever reaches a move line.
Tax is mapped to the destination by rate and direction, not by name. A source tax with no matching destination rate is dropped with a warning rather than substituting a wrong-rate tax that would distort GST or VAT.
Analytic distribution is carried to the mirror but company-scoped. Group-wide analytic accounts survive on the mirror line while source-company-only analytic accounts are stripped, so they never leak into the destination company.
A Represented Company field lets the counterparty partner stay global and remain usable on invoices in every company, sidestepping the standard company-consistency guard.
What is inside
Built to do the job, end to end.
- Trigger on post. When a sale invoice or vendor bill posts and its partner is linked to another company (via Represented Company, or the commercial partner's company) and that destination company has an enabled config, the mirror is built in the destination company. Refunds mirror too.
- Per-company configuration. One config row per company selects that company's mirror sale and purchase journals, the auto-post behaviour, and optional fallback income and expense accounts. The routing target comes from the partner's Represented Company, not a per-pair rule.
- Duplicate-proof linkage. An origin pointer plus a database-level unique(origin, company) constraint make re-posting and concurrent posts idempotent. A stat button jumps from either side to its counterpart, switching company context automatically.
- Review workflow. A stored lifecycle state (Not applicable, No mirror, Mirror draft, Amount mismatch, Matched) drives list badges, search filters and a dedicated Inter-company review action so a supervisor sees only pairs needing attention.
- Currency-aware mirroring. The mirror is created in the same currency as the source invoice with the same per-line amounts. It does not convert the amounts into the destination company's currency; both legs stay in the source currency.
- Cross-company-safe writes. The mirror is created with sudo() and the destination company context, the standard Odoo pattern for cross-company writes, without broadening the user's own permissions. Both invoices carry a chatter note linking to their counterpart.
Honest about the edges
What this does not do, so nothing surprises you.
- Mirroring does not convert currency. Both legs are created in the source invoice currency with the same per-line amounts; there is no day-rate conversion into the destination company's currency.
- Routing is partner-driven, not a per-company-pair rule. The destination is derived from the partner's Represented Company and each company has its own config; there is no sender-receiver-journal pair object.
- The mirror is not atomic with the source post. The source posts first and a mirror failure does not roll it back; the failure reason is recorded on the source chatter and flagged in the review queue for the accountant to resolve.
- A missing or disabled inter-company config is treated as mirroring-off and skipped silently, with no error raised.
- This module does not perform group consolidation or elimination entries; it builds the mirror invoice pair only. The only audit trail is the chatter note linking each invoice to its counterpart, not a separate append-only log model.
odoo intercompany invoicing, odoo automatic intercompany bill, odoo multi company sale to purchase mirror, odoo sister company invoice automation, odoo intercompany rules community, odoo group accounting multi entity, odoo mirror vendor bill from customer invoice, odoo 19 intercompany community, odoo intercompany journal automation, odoo cross company invoice automation
Languages
Available in 19 languages
The interface ships translated out of the box. Switch language in Odoo and the fields, menus, and messages follow.
Modules teams pair with this one.
Premium ERP Heritage modules that extend the same stack, each built to the same engineering bar.
Inbound webhook receiver for the Employment Hero people and payroll platform on Odoo 19 Community
Real-time fiscalisation of customer invoices and credit notes with the Mauritius Revenue Authority e-Invoicing (E...
The Canada country pack for the ERP Heritage Employment Hero integration
Imports finalised pay run journals from the Employment Hero payroll platform (KeyPay) into Odoo Community account...
Please log in to comment on this module