Is your ERP or store ready for Saudi e-invoicing integration?

Integration cannot compensate for missing source data. Review entity and branch identifiers, required customer details, product codes, amounts, taxes, discounts, and currencies where applicable. Is tax calculated in the store or in ERP? Does the total change after a voucher or delivery charge? Assign one source of truth for the final amount. If the storefront records one value and ERP invoices another, reconciliation fails even if every submission succeeds technically.

Take a representative sample of existing invoices with sensitive details removed and classify defects: missing fields, duplicate references, unclear return links, or undocumented manual corrections. Repair upstream rules before adding layers of mapping that hide bad data. Include the case of a return after an invoice is issued, not only cancellation before payment.

Map the journey from buyer order to payment or sales approval, document creation, submission, response, storage, and reporting. Give each stage a state: not created, ready, in progress, accepted, rejected, or requires action. “Sent” is not enough if the system has not saved the response. Staff need to understand what failed and what they may do next, while the system must prevent a second invoice from being created merely because the connection timed out.

Design retries and duplicate prevention. If the same event arrives twice, recognise the document and transaction identifiers instead of repeating the accounting entry. If a document requires correction after issue, avoid silently overwriting its history. The correct procedure should be confirmed with a qualified specialist and reflected in document type, reference, and approval records. Keep who approved the change, when, and why in the workflow.

Prepare ordinary sales, item-level discounts, order-level discounts, partial returns, cancellations, business buyers, and consumers where the operation serves them. Add connection loss, expired credentials, and rejected responses. A green test button is insufficient. Reconcile document totals with ERP records and make sure the team sees an actionable error without exposing sensitive information in a public log.

Run joint acceptance testing with finance, sales, and technology. A developer may see a successful request while an accountant notices that the day-end report does not match invoices or a return did not update the correct quantity. Sign off the scenarios and preserve them as regression tests for future store or ERP updates.

Assign an owner to inspect rejected and delayed documents each working day, with response and escalation rules. A useful dashboard connects document, order, customer, and response and makes unresolved states easy to filter. Do not send failure notices only to a technical mailbox nobody monitors. Maintain backups, an audit trail, and a recovery route if part of the integration is unavailable. Limit permission to cancel or resubmit documents.

A project may work at launch and fail after a change to ERP, a payment plugin, or product rules. Keep a test environment and representative difficult cases, then rerun them before impactful releases. Ask the supplier who supports the connection and how the team distinguishes bad business data from an API or external-service problem.

A customer pays in the store after applying a voucher and delivery charge. The order then moves to ERP for invoicing. The discount, delivery amount, payment method, and order identifier should arrive exactly as the store approved them. If a warehouse employee changes quantity after payment, the invoice must not silently change to a different amount without an explicit customer and finance process. Also test a one-item return from a multi-item order, a delayed payment notice, and a repeated order-transfer attempt. These cases expose which system owns each value.

Have the team map what happens at every discrepancy. Which system pauses the document? Who receives the alert? Who corrects the source? What evidence is reviewed before retrying? If there are no answers, process design must precede coding. The root cause may lie in order approval or product definitions rather than the external interface.

Before signing off, ask finance to reconcile a sample of invoices, adjustments, and reports against order records and document the result. Preserve a checklist to repeat after changes to tax rules, discounts, or payment configuration. Formal compliance interpretation remains with qualified specialists and the official authority; technology’s role is to produce correct data and an auditable trail.