When an accountant looks at a bank line, a receivable, or a tax line in Odoo, the immediate question is always "posted against what?" Odoo core stores each account.move.line with its own account, but there is no persisted field that answers the counterpart question — the offsetting account(s) on the other side of the same account.move. In practice teams reconstruct this by hand: opening each journal entry, eyeballing the balancing lines, or exporting to a spreadsheet and pivoting. On multi-line entries (a vendor bill with several expense accounts, a payroll entry, a bank statement with mixed allocations) the counterpart is genuinely ambiguous, and the native General Ledger and journal-item list simply do not carry the answer. That missing dimension slows reconciliation, VAT review, audit prep, and any analysis where you want to slice postings by the account they faced.

Account Counterparts is the module ECOSIRE builds for you to close that gap. We add a stored, indexed counterpart field (plus a human-readable label) to account.move.line, computed with a proper @api.depends method that runs over the sibling lines of the same move and derives the counterpart account using the opposite-sign convention — a debit line's counterpart is the credit side, and vice versa. For clean two-line entries the counterpart resolves to a single account; for multi-line entries we apply an agreed policy (dominant-amount account, concatenated account list, or per-analytic split — decided with you on the scoping call) so the behaviour is deterministic and defensible under audit. The field is exposed in the journal-items list and pivot views, added as a search/group-by dimension, and surfaced in the General Ledger and a dedicated counterpart QWeb report so you can read, filter, and print postings by what they were actually against.

Technically the work is a self-contained Odoo module: a __manifest__.py declaring the dependency on account, an ORM extension of account.move.line with the compute and its store/index settings, ir.model.access.csv plus any record rules to keep the new field inside your existing accounting access model, XML/OWL view inheritance for list, search and pivot, and a QWeb report definition. We recompute counterparts on post/edit through the depends graph (and, where a heavy historical backfill is needed, a one-time migration or queue_job-batched recompute so a large database is not locked). The field is readable over the XML-RPC/JSON-RPC API, so external BI tools and your data warehouse can consume the counterpart dimension directly. It respects Community vs Enterprise differences — nothing here requires Enterprise, and where your Enterprise General Ledger or consolidation views exist we inherit rather than replace them. Built and tested against Odoo 17.0, 18.0 and 19.0.

Delivery is build-to-order: we start with a short scoping call to lock the counterpart policy for your multi-line cases, confirm your version and Community/Enterprise edition, then build on a staging copy of your database, run UAT with your accountants, and cut over with a rollback plan. Typical delivery is 2–4 weeks from confirmed scope. This is not an instant apps.odoo.com download — you receive a version we build, install, document, and support for your database, with the git repository handed over to you. Pricing starts from $249 (indicative, single-company base scope); multi-company counterpart policies, historical backfill volume across many years of postings, localization-specific ledger reports, and BI/warehouse integration increase the quoted scope.