Test both sides of an intercompany transaction before buying automation

An intercompany transaction can be sent successfully without being posted by the receiving entity. During a software purchase, ask the vendor to identify every state between those events. The company needs to know where an amount waits, who can act on it and which status actually means that both ledgers contain the intended transaction.

Use two clearly named test entities and one approved transaction. Specify the amount, currency, counterparty accounts, expected dates and supporting reference for each side. The accounting owner should settle those facts before the demonstration so a mapping error is not confused with an unresolved accounting policy.

Business Central's inbox documentation distinguishes accepting, rejecting and canceling received transactions. It explains that accepting an inbox item creates document or journal lines that still need to be posted. That product example makes the central buying question concrete: what does the proposed system's accepted status actually prove?

Ask whether the implementation uses automatic acceptance, manual review or different treatment for different partners. If a setting removes a review step, identify the business conditions under which the company is comfortable doing so. A relationship within the same group does not eliminate the need to understand a transaction.

Open the sender and receiver in separate sessions. Have the demonstrator show the local account, shared intercompany identifier and destination account used for the transaction. A group account label may map to a different local code, so inspect the mapping rather than relying on similar names.

Include a department or project dimension that does not use the same code in both entities. Determine whether the receiving system maps it, substitutes a default or rejects it. The company should approve the result deliberately, especially where a silent default can send an expense to an unrelated reporting unit.

Create a controlled example with a missing mapping. Record where the error appears and whether anything has already posted in either ledger. The person responsible for resolving it should have enough detail to correct the mapping without changing unrelated transactions.

Check entity and currency context on every screen. The same counterparty name can appear across a group, and a shared service user may have access to several companies. Ask the ordinary operator to identify the sender, receiver and amount currency from the working screen without relying on memory.

Post the sending side and leave the received item unaccepted. Inspect the sender's status and the receiver's queue. Then accept it without posting and inspect the statuses again. This deliberately slow sequence reveals whether the product distinguishes the stages or compresses them into one reassuring completion label.

For a hypothetical $4,000 charge, the accepted but unposted receiving document should not be treated by the reviewer as evidence of a $4,000 posted payable. Compare the actual ledger entries in both entities. The demonstration should make the temporary difference visible and show who owns the remaining action.

Cross a reporting boundary in the test. Have one entity's intended posting date fall in a closed period or outside the user's allowed range. Ask what happens to the incoming item and whether an operator can change its date. Finance should decide how the resulting timing difference is approved and explained.

If the proposed design posts automatically, inspect the completion evidence produced after both sides finish. Ask how the controller finds items that failed during the sequence. A background integration running without a visible queue still needs a way to show incomplete ledger pairs.

Have the receiving entity reject the sample for a clear reason, such as an incorrect cost allocation. Watch how that decision reaches the sender. The rejection should identify the original reference and communicate enough information to distinguish a business dispute from a technical failure.

Inspect the sender's original posting after rejection. Do not assume that returning an inbox message reverses a ledger entry. Ask the vendor to demonstrate the required correction procedure and show the references linking the original charge, rejection and corrected transaction.

Next accept a transaction, then remove its unposted receiving draft through the supported process. Determine how the team recovers the work without creating an unrelated second charge. This case matters when a preparer cleans up drafts without realizing that a separate sender already considers the item delivered.

Test a disagreement that remains unresolved at close. The software should preserve the disputed status and source evidence in a form the relevant reviewers can use. A procurement evaluation should identify the supported workflow; it should not make the accounting decision about an actual disputed balance.

Repeat the same transmission safely in the test environment using the vendor's supported retry method. Compare document counts and ledger references before and after. The result should establish how the system recognizes an already received item or how the operating process prevents duplicate acceptance.

Ask which identifier remains stable across retries and corrections. A new transport message can still represent the same business transaction. The reviewer needs to distinguish a legitimate corrected charge from a second copy of the original, without comparing amounts and dates by hand every time.

Demonstrate the receiving preparer's role separately from group administrator access. Check who can change partner mappings, enable automatic acceptance and post received entries. Those permissions affect different parts of the process and should fit the company's intended separation of work.

Include a partner that is unavailable or outside the ordinary system connection. The vendor should explain the supported delivery method for the proposed deployment and the status evidence available. Do not assume an option described for an on-premises setup is also available in the company's hosted arrangement.

Request a report or inquiry that connects sender reference, receiver reference, amount, currency and final posting status. Have finance reconcile the sample pair using that output. The same view should expose items still awaiting delivery, acceptance, correction or posting.

Document which differences the automation is intended to prevent and which still require periodic reconciliation. The group may still need to investigate currency, timing and policy differences and perform consolidation work. Buying a transaction exchange does not by itself complete those separate responsibilities.

Include mapping maintenance, partner onboarding and exception ownership in the implementation scope. Accept the feature when the company can follow a transaction across both entities, recover a failed handoff and identify the exact remaining action without mistaking an intermediate message for a completed ledger result.