Xero returned HTTP 200, but some invoices were not saved

A successful HTTP response can coexist with individual invoice failures in a bulk Xero Accounting API request. If the integration marks every submitted invoice complete based only on HTTP 200, its local records can diverge from Xero even though the network request appears healthy. Start with the response for the exact submission and reconcile each requested invoice.

Xero documents an option, summarizeErrors=false, that returns individual entity results when creating multiple resources. Under that behavior, HTTP 200 can accompany validation errors. The documentation distinguishes OK, WARNING and ERROR outcomes. Confirm the endpoint and options actually used rather than assuming that another API or every Xero product follows the same response contract.

Also distinguish the response's processing result from the invoice's accounting lifecycle status. An invoice saved as a draft and an invoice rejected by validation are different outcomes. A field called status needs to be interpreted in its documented context before the integration uses it to drive a finance completion label.

Keep an inventory of the submitted records with their internal source identifiers, intended entity, amounts and relevant request version. Match the returned entities to that inventory using the supported references. Preserve destination identifiers for records that were created. Response order alone should not be the only evidence connecting an outcome to the intended business invoice.

Account for every original record exactly once. A missing outcome needs investigation rather than an assumption of success or failure. Inspect the original request and response through authorized tooling and retain the necessary references. Do not place full invoice payloads or customer personal data into an unrestricted monitoring channel merely to make debugging convenient.

Use separate states for saved without an identified warning, saved with a warning requiring review, failed validation and unresolved outcome. Those states support different actions. A single completed flag loses the distinction the finance team needs when deciding whether an invoice exists and whether its contents still need attention.

Make the reconciliation available to the person responsible for the source invoices. A developer may understand a validation message while the preparer knows which contract or customer record supplies the missing fact. Link the technical exception to that business owner and the original source reference, so the correction can be supported without requiring finance staff to interpret an entire API response.

Xero states that a WARNING means the entity was processed successfully with additional warnings, while an ERROR indicates it could not be saved because of a validation problem. That distinction matters for retries. Resubmitting a warned invoice as though it never existed can create a second problem while leaving the original warning unexplained.

Read the warning's actual message and route it to the appropriate owner. The integration should preserve it and make it visible where the finance process can respond. Do not infer a particular accounting correction merely from the word warning. The returned detail and source records should establish what needs review and whether the saved invoice is usable for the intended next step.

For failed validation, identify the field or business condition that prevented saving. A missing reference, unsupported combination or incorrect value may require different input corrections. Have the source owner approve any substantive change. Replacing rejected data with convenient defaults just to obtain a saved record can create misleading accounting evidence.

Consider a fictional submission of twelve invoices totaling $6,000. Eight invoices totaling $4,000 are saved without warnings, two totaling $1,200 are saved with warnings and two totaling $800 fail validation. The saved population is ten invoices totaling $5,200, while $800 remains unsaved. The two warnings still require the agreed review even though their records exist.

Reconcile the categories back to the original submission: eight plus two plus two equals twelve, and $4,000 plus $1,200 plus $800 equals $6,000. This schedule prevents the operator from treating the entire file as either successful or failed. In a multicurrency submission, perform the monetary reconciliation separately for each currency.

State the amount basis, such as invoice total including tax, and keep it consistent between source and destination checks. If the destination calculates additional fields, explain the expected difference through the approved invoice rules. A count match alone cannot establish that amounts and customer assignments were saved correctly.

Build the correction population from the verified failures, with the original source references and the approved changed fields. Use the endpoint's supported creation, update and duplicate-prevention behavior. A whole-file retry should not be the default response to two failed invoices when ten have already been saved.

Treat a lost or incomplete response as a separate uncertainty. If the request might have created a record but the application did not retain the answer, establish the destination state before deciding whether to create another. This case cannot be resolved merely by applying the rules for an explicit validation error. Preserve a visible unresolved state until the evidence is sufficient.

After correction, reconnect the retry outcome to the original submission. The control record should show which invoices succeeded initially, which were corrected, which warnings were resolved and what remains outstanding. Do not replace the original failure evidence with a later green status that makes the history impossible to reconstruct.

Have the integration owner demonstrate a controlled batch containing both valid and intentionally invalid fictional invoices in an authorized test environment. Verify that the application displays individual outcomes, retains identifiers and does not mark rejected entities as saved. Include a warning case where a supported test can reproduce one safely.

Keep the provider-specific response interpretation with the connector's operating instructions. Revisit it when the endpoint, request options or response handling changes. The finance task is complete when every submitted invoice has an evidenced disposition and the saved records match the approved business intent, not when the HTTP request alone has a successful label.