{"section":"known-issues","requestedLocale":"en","requestedSlug":"invoice-accepted-with-value-higher-than-order-total-via-orders-api-during-concurrent-change","locale":"en","slug":"invoice-accepted-with-value-higher-than-order-total-via-orders-api-during-concurrent-change","path":"docs/en/known-issues/Order Management/invoice-accepted-with-value-higher-than-order-total-via-orders-api-during-concurrent-change.md","branch":"main","content":"## Summary\n\n\nIn some cases, when a **Change** and an **invoice** submission happen almost at the same time for the same order, the system may rely on out-of-date information about the invoiced amount.\nThis can cause:\n\n- **Invoice with a value higher than the final order total** (the invoice is accepted based on the order value before the reduction Change is fully completed).\n- **Order stuck in** `payment-approved` **even with a valid invoice** (the invoice exists in an external system but is not found by the workflow at validation time, which interprets the situation as a partial invoice and does not move the order to `invoiced`).\nIn both scenarios, the root cause is the near-simultaneous execution of **Change** and **Invoice**, which leads to inconsistencies between the actual invoiced amount and the final order state.\n\n\n#### Simulation\n\n\n\n**Prerequisites**\n\n- Use the Orders API endpoint:\n`POST /api/orders/pvt/document/{orderId}/invoices`\n- Have an integration that:\n  - Triggers invoicing on a status change (for example, `handling`), and\n  - Almost simultaneously sends a partial cancellation / value-reduction Change for the same order.\n**Steps**\n\n1. Trigger the “handling” (or similar) status so that the system/integration attempts to invoice using the order’s `updatedOrderValue`.\n2. Within a very short time window (for example, 50–1000 ms), send a Change request that reduces the order value (partial cancellation).\n3. Observe that the invoice may be accepted with the **pre-Change** amount, resulting in an invoice value greater than the final order total after the Change finishes processing.\n\n##\n\n\n#### Workaround\n\n\n**Sequence controls in the integration**\n\n- The integration that calls the invoice endpoint must implement controls to ensure that the value-reduction Change has finished **before** invoicing.\n- To do this, the integration should:\n  - Query the Change status via the appropriate endpoint (for example, the endpoint that returns the Change object for the order), and\n  - Validate that the `finished` field is `true` before sending the invoice request.\n- Once `finished = true`, it means the Change has completed and the order totals are updated, so the invoice with the new (reduced) amount can be safely sent."}