Preserve the selected billing organization when a request reaches invoicing

A correctly displayed amount can make an incorrect business transfer look convincing. The decimal value, currency and total may all agree while the receiving draft names the wrong buyer. Formatting checks and transfer acknowledgements cannot establish that relationship.

This fictional example follows request R-61 from a Dutch-language customer form into a supported invoicing tool's isolated draft environment. It concerns an approved billing-entity choice, a delivery site and their separate references. No invoice is issued, payment collected or tax treatment determined during the exercise.

Record the approved identities and amount

A purchasing contact is authorized in the fixture to request work for billing organization B-2, Canal Technical Services. Delivery site D-8 appears in a shared location register under B-1, Canal Group Holding. The approved request explicitly selects B-2 as the buyer; D-8's registry parent is not the authority for that selection.

The approved fixture total is 1,234.50 EUR. The Dutch review view presents it as € 1.234,50; a French review view uses 1 234,50 €. Those are the chosen presentation examples, not a rule that every Belgian form must accept or display identical punctuation. Both views refer to the same numeric value and currency.

The organization and its accountant approve the billing requirements used by the real implementation. This table defines test relationships; it does not establish whether a transaction is within a particular invoicing obligation.

Trace the wrong substitution

The saved request retains bill_to_entity_id=B-2. The integration then builds the provider draft using delivery_site.parent_entity_id, which resolves to B-1. The receiving tool accepts the payload and creates unissued draft INV-D61 for B-1, amount 1234.50 EUR.

The reviewer compares three pieces of evidence: the customer's selected buyer, the stored request and the prepared provider payload. The first two agree on B-2. The payload introduces B-1. The error is therefore in field selection during draft preparation, not in the language form or the display conversion.

A total-only reconciliation would pass. A successful provider response would also pass. Neither examines the question the customer actually answered: which organization is being billed?

Make the explicit selection authoritative

The corrected preparation uses the approved billing organization reference from R-61, after applying the actual authorization and provider-account rules. It retains D-8 as a distinct delivery-site value where supported. It does not replace the site register's parent or rename B-1 to make the records appear consistent.

Unknown or unauthorized billing selections go to the agreed validation or review path. Falling back silently to the delivery site's parent would recreate the defect whenever the intended reference is missing.

In this fixture, the inspected provider supports editing the buyer on an unissued test draft. The reviewer changes INV-D61 from B-1 to B-2 through that supported draft-edit action. Its history retains the original B-1 assignment and the correction; INV-D61 remains the same unissued draft. No issued invoice is overwritten, and this procedure is not assumed to exist in another provider.

Verify the corrected draft through the ordinary review role

The reviewer first inspects recovered INV-D61 through the ordinary invoice-review role and confirms B-2, R-61 and the expected amount. That proves recovery of the existing test draft, but not that a newly created draft will use the corrected field-selection rule.

A fresh isolated request R-63 therefore selects B-2 and D-8. Its prepared payload uses B-2, and the newly created INV-D63 shows Canal Technical Services with the expected amount, currency and R-63 reference. The original corrected INV-D61 remains linked to R-61. Creating R-63 does not replace that earlier request or merge the two drafts.

The Dutch and French amount views are checked again against the stored numeric value. This confirms that the buyer correction did not solve one problem by creating another. The test does not parse a formatted display string as the source of the amount when the authoritative numeric value is already available.

Control draft INV-D62 belongs to separate buyer B-3 and deliberately has the same 1234.50 EUR total. It retains B-3 and its own originating request. That control catches a repair which finds drafts by amount alone and changes the wrong customer's record.

Keep invoice and payment evidence separate

The corrected INV-D61 and newly created INV-D63 remain unissued drafts in this exercise. Neither draft may be marked “paid” merely because the provider accepted its creation. No payment receipt exists for R-61. Correcting the buyer changes neither that fact nor the independent draft's state.

A real payment journey needs its own provider references, approved amount, supported test facilities and recovery rules. A payment-provider response cannot be treated as proof that the accountant's invoice workflow has completed, just as an invoice transfer does not prove that money was received.

Belgium's official B2B invoicing guidance provides current starting points for the accountant and software provider. They determine applicability and the supported invoice exchange. A website form, portal PDF or correct draft mapping is not a general compliance certificate.

Keep the acceptance record about the actual decision

Record R-61's selected B-2, the erroneous B-1 substitution, the supported INV-D61 edit and its retained history. Add the fresh R-63/INV-D63 result proving the corrected field-selection rule, alongside the unchanged B-3 control. Include the two display checks, numeric amount and retained unissued/unpaid boundary.

The result is a verified relationship rather than merely another successful API call. Business integrations can establish the field authority and receiving checks; forms and intake establish how the customer makes the intended selection in the first place.