Intercompany Orders in a Business App: Which Counterpart Document May Be Created Automatically?

When one company in your group sells to another, decide whether the app should prepare the other company's document or also confirm it. Automatically creating a purchase draft is different from authorising a purchase. A shared database does not remove that distinction.

Start with the commercial relationship, not a company switcher. Identify the seller, buyer, documents each party needs and the event that may create the counterpart. Have the responsible financial advisers approve prices, tax treatment and accounting configuration. This guide does not determine those policies or recommend creating a separate legal entity.

Distinguish a sale between companies from an internal stock move

Moving goods between two warehouses of the same business and selling goods between two companies are different requirements. Both can involve dispatch and receipt, but a physical journey alone does not define the commercial documents.

Odoo 19's multi-company guide describes intercompany transactions as sales or purchases of goods and services between companies in the same database. Depending on configuration, it can generate counterpart orders and invoices. It requires shared product records for the involved companies and warns that the general and specific setup, including fiscal positions and localisations, must be correct.

For your brief, draw one fictional transaction with the two legal entities and their respective documents. If the real need is merely an internal transfer, do not add a reciprocal purchase-and-sale process just because it is available in a menu.

Name the event and the resulting state

Avoid the instruction “keep both companies in sync.” It leaves unanswered which event leads and what the receiving company is being asked to accept.

Odoo gives concrete examples: confirming a purchase order can create a quotation for the counterpart, while confirming a sales order can create a request for quotation for the other side. It separately offers automatic validation of the generated records. Its billing option can create a counterpart bill or refund when the originating invoice or credit note is confirmed.

Choose the required direction deliberately. A buyer's confirmed order might prepare a seller's quotation, leaving the seller to review it. Alternatively, an explicitly approved process may allow validation. Those are different authority boundaries, even if both save typing.

Write a short mapping for each enabled document type: originating company, initiating event, receiving company, counterpart type and intended initial state. Record who may change that configuration. Do not assume that enabling one useful direction authorises every available automatic counterpart.

A counterpart needs a traceable relationship

For a commissioned implementation, require users to find the related document on the other side, subject to their access permissions. Matching amounts and similar customer names are not a reliable relationship identifier.

A generated draft should remain recognisable as such until the agreed confirmation step. Ask how changed quantities, prices or references are handled before and after that point. Do changes propagate, stop for review or require a linked correction? The answer must be explicit rather than inferred from the word “synchronised.”

Also define recovery from an uncertain result. If the initiating system cannot tell whether a counterpart was created, the review process should look for the original linked result before creating another. A missing response is not evidence that the other company has no document. These traceability and reconciliation controls are proposed requirements; the cited page does not prove a complete duplicate-prevention implementation.

Keep warehouse events and document authority visible

Odoo offers stock-move synchronisation as a separate intercompany option and describes a selected warehouse for relevant order generation. Its documentation also notes that warehouses for additional companies are not created automatically after the initial database setup.

Ask the implementer to verify the actual warehouse configuration for each company. Do not allow a convenient default to choose where another company's goods are expected.

Where delivery synchronisation is enabled, demonstrate its specific effects. A reciprocal order is not evidence of dispatch, and a synchronised stock action is not proof that every commercial and financial step is complete. Keep the agreed receiving, exception and approval responsibilities clear.

Demonstrate one complete pair and one failed handover

Use fictional companies and products in the acceptance criteria. Trigger the approved originating event, inspect the generated counterpart and check its company, warehouse, references and initial state. Confirm that a draft-only configuration does not validate the receiving document.

Then test an unavailable configuration, an uncertain response and an attempted change after the receiving side has confirmed its document. The reviewer should see the unresolved work and the authorised next step, not a falsely reassuring green badge on only one side.

For a business-app planning discussion, bring one blank paired-document example and identify who has authority in each company. The useful automation removes repeated entry while preserving two explainable business decisions. It does not turn a shared login into permission to commit both companies.

Evidence boundary

Odoo's official guide supports the described counterpart options, optional validation, product-sharing prerequisite, configuration warning and warehouse considerations. The proposed linkage, uncertain-result handling and acceptance cases are project requirements, not independently tested features or legal assurances.