Blog Overview
ERP integrations rarely fail in the demo; they fail in field mapping, status handling, and error reporting. This checklist defines scope, discovery questions, cost drivers, and what to send before you request a quote.
A Saudi company requested an ERP integration quote after invoices, orders, and inventory sat in three systems that did not talk to each other. The expected reply arrived within two days: a fixed price, a short timeline, and no mention of field conflicts, retries, or reconciliation. Three months later the problems started: one transaction appeared twice, responsibilities were unclear, and reports matched none of the source numbers. The intent was not the problem. The problem was a quote written before the integration scope was defined in writing.
ERP integration decides who owns the truth when records disagree: which system sends, which receives, what happens on failure, and how you detect that totals do not match. If those questions stay open while you request a price, the vendor prices the simplest version of the solution and adds changes after signature. This guide gives you the discovery questions, the failure points, the cost drivers, a before and after table for errors and monitoring, and what to send before the call.
Define the integration scope before you ask for a price
Good scope starts with one line per integration: what the source system is, what the target system is, which objects move between them, and in which direction. A working example: invoices from the ERP to the portal, with no return flow. Or orders from the portal to the ERP with idempotency keys, and stock states synced hourly. One line prevents the most expensive dispute: one side assuming real-time sync, the other assuming a nightly update.
Add three boundaries to that line: the time window the sync covers, how historical records are treated, and who owns this integration after handover. An integration covering ten months of history is not the same as one covering today's transactions only. The owner decides who fixes the failure, who enters data manually on error, and who reads the error log. At Rasad we treat enterprise systems as a scope document before a coding project: if we cannot write source, target, and direction for each flow, we do not quote. If the integration includes e-invoicing, the ZATCA Wave 25 readiness guide sets out the regulatory requirements that belong in scope from day one.
The discovery questions that decide the estimate
Start with the source system. Which system counts as the truth for each object, and which one is the copy? Ask the same for every field: which customer identifier does the integration trust, the account number, the tax number, or the email? Then ask about directions directly: is the connection one-way or two-way, who initiates calls, who answers events, and who carries the outage risk? A two-way flow needs an agreement for two sides editing the same record at once, while a one-way flow needs only a schedule and duplicate prevention.
Then ask for volumes, error handling, idempotency, and reconciliation as numbers, not adjectives. How many records per hour? How many fields per object? What is the timeout when the other side is down? What is the retry policy: how many attempts, at what intervals, and when does a retry become a manual error? Idempotency means the same request does not create a second record even if it arrives twice. Reconciliation means a scheduled report that matches totals on both sides and shows gaps with their causes. Those six figures convert into weeks, so if a short session cannot answer them, any estimate stays in guesswork territory.
Where ERP integrations actually break
The first break point is field and code mapping. A field that looks identical is not always the same value: a country arriving once as digits and once as a code, an order status that closes in one system and stays open in another, a discount meaning a percentage on one side and an amount on the other. The break surfaces months later, when edge cases the first sample never showed have piled up. Do not ask for “field mapping.” Ask for a field-by-field table with accepted values, who owns each code, and what happens on an unexpected value.
The second break point is status codes and system responses. Every API answers with its own codes, and some answer success even when the record was never saved. A sound integration knows what each response means and links it to a clear step: success, retry, or human error. The third break point is time and Hijri dates. A birthday, weekend, or accounting period can name a different day after a timezone or calendar conversion, and the error shows not in the invoice but in its due date and payment terms. The fourth break point is approval chains: who approves, up to which amount, and what happens when the approver is away? If the approval chain is not drawn on paper, the system will discover it in the first month of operation.
Six cost drivers you can check before the quote
The first driver is the count of integrations and objects, not the count of systems. Two integrations exchanging five objects cost more than three exchanging one object. The second driver is mapping depth: every code list and conversion rule adds testing and documentation. The third driver is sync mode: real-time calls, schedules, and webhooks differ in architecture and monitoring. The fourth driver is error handling and reconciliation: a message queue, a dead-letter area, and a reconciliation report are not cosmetic extras, they are the column that protects the numbers.
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
The fifth driver is testing and cutover: a sandbox, realistic test data, acceptance cases, and a rollback step. The sixth driver is data quality and cleanup before linking, because cleaning duplicate codes in the source system moves into the integration if work starts on dirty data. At Rasad, the published band for enterprise systems is SAR 25,000 to 35,000 over 12 to 20 weeks. The lower end assumes scope defined in writing and one or two designed integrations. The upper end assumes a two-way direction, historical data, or an approval chain. The price does not move because a company is in a hurry. It moves because the answers above change.
Errors and monitoring: before and after
Spotting the gap takes one table that a non-engineer can read. The table below shows what things look like before error handling is set up at launch, what they should look like after, and why the difference matters for the numbers you sign off. This before and after is what we require in every live integration, as in any portal connected to an outside system.
| Area | Before | After | Why it matters |
|---|---|---|---|
| Idempotency key | A repeated request creates a second record | A stable key blocks the second write | Stops inflated invoices and orders |
| Retries | One attempt, then the request is lost | A queue with back-off, then manual review | Turns silent failure into a clear decision |
| Error area | Errors sit in log files nobody reads | A searchable error list with fixes | Cuts resolution time from days to minutes |
| Reconciliation report | No scheduled comparison between sides | Daily matching by totals and gaps | Surfaces any missing record before close |
| Alerts | Mailbox alerts with no priority | Alerts by threshold, type, and owner | Reaches the owner before the error grows |
| Dates and timezone | Implicit conversion by server settings | Explicit dates stored as absolute values | Removes due-date and payment-term errors |
Note that none of the “after” items needs new technology. Each needs a written definition before the code. Companies that built this table in week one saved time and saved the value of the whole integration: proving the numbers is no longer a later audit task, it is a daily property. The same principle applies to client portal interfaces that show financial data in Arabic and English: the experience must stay readable and measurable, against the published performance thresholds and the accessibility criteria that respect screen readers and keyboards on every path.
What to send before the call
Do not go into the call with a spoken description. Send a short text list before the meeting and ask for written replies on open items. The list below is what we ask of any company before quoting an integration, and it is also what protects you if you hire a different team.
The systems involved. The name of each system and its current version if known, plus a technical contact on each side.
The source of every object and field. A half-page table naming the truth for each object and the accepted code for each field.
Direction and schedule. Whether each flow is one-way or two-way, the sync intervals, and the timeout on outage.
Approximate volumes. Record counts in the peak period, fields per object, and the target size after one year.
Retry and idempotency policy. Attempt counts and intervals, plus the key used to block duplicate records.
Status and approval chains. The states of each object, who approves and up to what limit, and what happens when the approver is away.
Reconciliation and monitoring. Who matches the numbers, how often, where alerts land, and who reads the error list.
Scope boundaries. What stays out of the first phase, who signs that boundary, and when it is reviewed.
If you send those eight items in full, you can compare any two quotes on the same basis. If one item cannot be gathered, write “unknown” rather than guessing. An honest estimate starts by admitting what you do not know. That is where a scope-minded team differs from a team selling hours: the first welcomes an incomplete list and tells you where to find the missing piece and how to collect it, while the second fills the gap with an assumption and issues a pricey quote on top of it.
On Rasad: we have delivered 45+ projects with 3 government entities over 5+ years of shipping. The number does not mean every project is alike, it means we have seen enough integration failures and finance teams to understand why the mapping table matters more than a polished interface. If you want us to build or review this integration, see enterprise systems and send the list above and you will get a comparable reply in clear weeks.
Frequently asked questions
Do we need to change the ERP before integration? Usually no, but you need cleaned duplicate codes and one source map. Change comes when the system cannot expose a stable API or the version restricts the external side.
Are Hijri dates really required? Yes, if reports or due dates follow a Hijri calendar. Storing absolute values and rendering by the required calendar prevents deadline errors.
What is a realistic timeline for a defined scope? The published enterprise systems band is 12 to 20 weeks. Time follows the six discovery answers, not the launch wish.
Who owns the error log after handover? The team running operations, with search and fix rights, not the team that finished building. Write the owner down.
Is a daily reconciliation report needed from month one? Yes, because it is the only early signal for a missing record before it becomes a wrong accounting entry.
Sources
- OASIS — open standards beneath enterprise integration contracts.
- ZATCA: Wave 25 e-invoicing criteria — a live regulatory requirement that changes any finance system scope; deadline 1 February 2027.
- PDPL Implementing Regulation — the official reference for processing, disclosure, and breach duties.
- web.dev: Core Web Vitals — the performance thresholds portal interfaces are measured against.
