This is the comparison run most often in Saudi enterprise ERP selections, and it is also the one run badly most often - because the two platforms are not competing for the same job as frequently as the pairing implies. Oracle NetSuite ERP is a cloud suite built to give a growing, multi-entity organization one integrated set of books quickly. SAP S/4HANA is an enterprise process platform built to run deep, industry-specific operations at scale. Both are very good at what they were built for. Neither is a smaller or a larger version of the other, and scoring them on one feature matrix produces a confident answer to a question that was never the real one.
So this page does two things. It gives you the decision rule first, then the evidence behind it - the criteria that actually separate the two in this market, in enough detail to apply to your own case, and two sets of conditions written so that each is genuinely invertible: the circumstances in which we would tell you to choose NetSuite, and the circumstances in which we would tell you to choose SAP. A comparison that cannot produce the second list is marketing.
Our interest, stated before the argument rather than after it. We work with both platforms on this page and can deliver either. That is a commercial interest in your decision and you should have it before you read another paragraph, not discover it on a partners page afterwards. We hold no reseller or distribution agreement for either product and earn nothing from which one you license - but implementation revenue is an interest in its own right, and comparison pages routinely omit it. Section 8.1 sets out what we do about that, and what you should require in writing from anyone - us included - before they advise you on this choice.
For most Saudi organizations running this comparison, NetSuite is the right answer - and the reason is not that it is the better product. It is that the profile which reaches this comparison most often is a growing, multi-entity group carrying real financial and operational complexity but no deep discrete or process manufacturing, and that is precisely the profile the suite was built for. It produces one integrated set of books across entities, it implements in a timeframe a business can absorb, and it does not assume a standing internal capability that an organization of that size usually does not have and would have to hire.
Choose SAP S/4HANA when the complexity is in the operation rather than in the reporting. If what you actually run is discrete or process manufacturing, a regulated supply chain, plant maintenance on physical assets, long-running engineering projects, or a group whose statutory and management reporting is industrial in scale, then S/4HANA stops being over-buying and becomes the honest requirement. In those cases recommending the lighter suite would be cheaper for you this year and wrong for you within three, and we say so - at length, in section five.
And a third answer, more common than either vendor would like. A meaningful share of the organizations that arrive at this comparison should not be running it, because the constraint they are trying to solve is a process, a data or an integration problem that a platform change will inherit rather than fix. Section six is that conversation, and it is the one no vendor-funded comparison contains.
Three things flip the default, and they are worth naming, because a recommendation you cannot invert is a preference wearing the clothes of an analysis:
Everything below is the evidence for that, plus the criteria you need in order to disagree with it intelligently for your own case.
What follows compares character, not features. A feature grid is obsolete the quarter after it is published and, worse, it flatters whichever product its author knows better. These are the structural differences that hold across releases and that actually decide the outcome. Verify anything here that will carry weight in your decision against each vendor's current documentation and against your own scripted scenarios - section 8.2 explains how this page is kept current and what it deliberately does not claim.
| Dimension | Oracle NetSuite | SAP S/4HANA |
|---|---|---|
| What it is built to be | An integrated cloud business suite - financials, order management, inventory and reporting in one system | An enterprise process platform - deep, configurable industry operations, with finance as one domain among several |
| Where its depth lies | Multi-entity financials, consolidation, order-to-cash, distribution and services delivery | Manufacturing, supply chain, plant maintenance, quality, and industry-specific process models |
| Deployment model | Vendor-operated cloud, one shape for everyone | A choice of deployment models - which is itself a decision, with real consequences for cost, control and who operates the platform |
| Upgrade model | Vendor-managed on a published cadence; staying current is largely absorbed for you | A planned activity you own to a greater degree, and one that varies with the deployment model you chose |
| Extension and customization | Configuration plus supported platform extension inside the suite | Configuration plus extension through the vendor's platform layer, with a stronger formal line between extending and modifying |
| Multi-entity consolidation | Core to the product rather than configured on top of it | A genuine strength, typically configured, and usually involving more of the platform |
| Saudi localization | Both are used compliantly in the Kingdom today. The question is never whether the product can be made compliant, but whose integration you are buying, in what form, and who owns it when the requirement moves - see section 3.3 | |
| Implementation profile | Shorter and more standardized; fewer moving parts and fewer roles | Longer; more configuration, more specialist roles and more governance |
| Internal capability it assumes | An empowered business owner and a capable administrator | A standing internal competence, and in practice a named team |
| Cost shape | Subscription plus a services envelope, weighted to the front and flattening afterwards | A broader envelope that keeps running: platform, deployment, a larger implementation, and an internal capability that is a real annual cost |
| Where it most often goes wrong | Complexity that was real gets flattened into configuration that does not fit it | Complexity that was never real gets automated, and then locked in for a decade |
Read that table as a shape rather than a scoreboard. Nothing in it says one platform is better; every row says the two are built around different assumptions about who you are. The next section is where those assumptions get tested against your case.
Six criteria decide this comparison in Saudi Arabia. They are ordered by how often they turn out to be decisive rather than by how much attention they usually get, which is close to the reverse order. Functional feature depth is not among them, and that is deliberate: by the time an organization is choosing between these two platforms, both will do most of what is on its requirements list. What separates them is what each costs to own, how each behaves as your complexity grows, and whether the people and the local capability exist to make the choice work here.
We publish no price for either platform and no comparative figure between them, and the reason is not discretion. Both are quoted against your scope, your user counts, your modules, your entity count and your negotiating position, and a number published on a page cannot know any of those. A figure invented for a web page would anchor your budget on something nobody can stand behind, which is worse than no figure at all. What can be published honestly - and is far more useful when you are holding two quotations - is the shape of the cost and where the two differ structurally.
The subscription or licence is the part everyone compares and the smaller part of what you spend. On both platforms the services envelope - implementation, configuration, data migration, integration, training, hypercare - is typically the larger line, and the ratio between the two differs enough that comparing licence quotes alone can invert the real answer.
NetSuite's cost concentrates at the front and then flattens. A subscription that scales with users, modules and entities; an implementation weighted toward configuration and data rather than build; and upgrades absorbed by the vendor, so the recurring cost of staying current is low and predictable. Growth in spend comes mostly from adding users, entities and modules, which makes it straightforward to model.
SAP S/4HANA's cost is broader and keeps running. The platform itself, the deployment decision and whatever infrastructure and operations it carries, a larger implementation with more specialist roles, release and upgrade management you own to a greater degree, and a standing internal capability that is a genuine annual cost even though no invoice arrives for it. For an organization that needs the platform this is a fair price for real capability; for one that does not, it is an annual premium on capability nobody switches on.
The lines most often missing from both quotations. The e-invoicing integration and its own recurring fee, which is frequently a separate product or a partner build; sandbox and test environments; the second round of training nobody budgets for after go-live; modules that turn out to be licensed separately; the annual support and maintenance percentage; your own people's time, which is a real cost with no invoice; and the cost of adding the next legal entity, which is rarely proportional to the first.
Compare over five years, not at signature. One template, filled in by both vendors, with the same assumptions about growth in users and entities. Two quotations that look close in the first year routinely separate by a wide margin by the fifth, and the direction of that separation depends on your own growth profile rather than on the platforms.
Scalability in ERP is two different questions sharing one word. The first is volume - transactions, users, locations. Both platforms handle volume well past the point where most organizations in this market operate, and it is rarely the constraint that bites. The second is complexity: how much irregularity, how many exceptions and how much industry-specific process the system absorbs without being fought. That is the question that decides this comparison.
NetSuite scales breadth well and depth less well. More entities, more currencies, more locations, more users - this is what the suite is built to absorb, and it absorbs them without a re-implementation. Where it strains is depth in a specialized operational process: the production floor planned against constrained capacity, the regulated batch traceability requirement, the maintenance regime on physical assets. It can often be extended toward those, and the honest question to ask is whether you are extending a product toward a capability or bending it away from its design.
S/4HANA scales depth, and charges you for it. The depth is genuinely there and for organizations that need it there is no cheaper way to get it. The cost is that the platform assumes configuration, governance and internal capability continuously, not only during implementation. Organizations that need the depth find that a fair trade. Organizations that bought the depth because it was available pay the premium and never collect on it.
Customization is where the long-term difference actually shows. Both platforms distinguish between configuring what the product already does, extending it through supported tooling, and modifying it. The first is cheap and safe on both. The second is a real engineering activity on both and should be scoped as one. The third is where cost of ownership is decided: heavy modification turns every subsequent upgrade into a project, and it is the most reliable predictor we see of an ERP that becomes expensive to own five years after a successful go-live.
One rule applies to both, and it is worth writing into the program charter: every customization request during implementation should have to answer why the process cannot change instead. Most cannot answer it. The ones that can are usually the genuine competitive difference in the business, and those are worth building. An implementation that automates the rest locks in a decade of your current habits, and neither platform will warn you that it is doing so.
This criterion eliminates rather than scores, and it is the one where this page will not publish what you probably came here for. We do not state either vendor's current compliance status, and you should treat any page that does with caution. Compliance attaches to a specific solution and version rather than to a brand, it is frequently delivered by a middleware product or by an implementation partner rather than by the ERP vendor at all, and it moves as the requirement moves. A tick beside a product name on a page written months ago is a claim about a live regulatory status that its author cannot stand behind, and publishing one would make this page unreliable in exactly the way it argues against.
What we publish instead is the verification method, which stays true for as long as the regulation does. Both platforms are used compliantly in the Kingdom today. The question is never whether the product can be made compliant; it is whose integration you are buying, in what form, and what happens to it next year. Five questions settle it, and they are the same five for both platforms.
Whose compliance is it? Ask which entry on ZATCA's own published list of compliant solutions your integration runs under, and whose it is - the vendor's, a middleware provider's, or your implementation partner's. All three are legitimate, and they carry completely different renewal costs, support paths and answers to the question of who fixes it when the requirement changes.
Is it live here, at your scale? Ask for a reference running the same version with the same integration at a comparable volume, in the Kingdom. "Certified" and "live at a company like yours" are different claims, and only the second predicts your experience.
What happens to the edge cases? Credit notes, debit notes, returns, foreign-currency invoices, self-billing arrangements and cancellations are where the gaps actually appear. A clean sales invoice demonstrates almost nothing.
Who absorbs the next regulatory change? Establish in writing whether adapting to it is covered by your subscription and support agreement or is a chargeable project, and get that into the contract rather than into an email.
What does it cost per year, and per what? Some integrations are priced per document, per entity or per connection. That is a cost line which grows with your business and which rarely appears in the licence comparison you are shown.
That the same five questions apply to both platforms is itself the finding: on this criterion the distance between NetSuite and SAP S/4HANA is far smaller than the distance between two implementation approaches to either one. Arabic deserves separating out too. An Arabic interface and correctly rendered Arabic outputs - invoices, credit notes, statements, the documents an auditor actually reads - are different pieces of engineering, solved to different standards by the same product. Ask both candidates for a real printed and PDF Arabic credit note from a live system rather than a template mock-up, and check the mixed Arabic-Latin lines and the totals.
Almost no ERP in this market runs alone. There is a point-of-sale estate, or a warehouse system, or a payroll product, or a bank connection, or an e-invoicing middleware layer - usually several of them. Integration is where a correctly chosen platform still fails, and it is systematically under-scoped during selection because it is nobody's headline feature.
Both platforms integrate through modern, documented interfaces, and both have established middleware and partner ecosystems around them. The differences worth weighing are practical rather than technical.
NetSuite's integration surface is narrower and more uniform, because there is one code line and one deployment shape. What you build against is what everyone builds against, which makes third-party connectors and partner experience more transferable and makes it easier to find someone who has done your specific integration before.
S/4HANA's integration surface is wider and depends on the deployment you chose. The same integration is a different piece of work in one deployment model than in another, and the pattern you find documented may not be the pattern available to you. That is not a weakness - it is the cost of the flexibility that makes the platform right for some organizations - but it needs pricing during selection rather than discovering during design.
Three questions matter more here than the platform choice does. Who owns each interface once it is live, and what happens to it when either side upgrades? Is the integration real-time or batch, and does the business process it supports genuinely tolerate the answer? And what is the reconciliation mechanism when the two sides disagree - because they will, and an integration without one becomes a monthly manual investigation that nobody scoped and nobody owns. Our enterprise systems integration page covers how that work is scoped, owned and handed over.
This criterion decides more Saudi ERP outcomes than the software difference does, and it is the one least likely to appear in an international comparison. The best-fitting platform with no credible local capability behind it is the wrong answer. Both platforms have real depth in this market - but they have it in different shapes.
SAP has the longer institutional presence in the Kingdom and the larger pool of experienced people, particularly in the sectors where it is entrenched. It also has the greater concentration of that talent inside large programs, which makes availability on your timeline a real question even where the skills plainly exist in the market.
NetSuite's local capability is younger and narrower but more uniform, and a smaller team can carry an implementation end to end. The risk to test on this side is continuity: a smaller pool means the departure of one or two people has a larger effect on your project than it would on the other platform.
How to score it for your own case, on both sides. Ask for named consultants rather than a partner logo, with their availability on your dates in writing. Ask what proportion of the delivery team will be in the Kingdom and in your working hours. Establish support hours and support language as a service level, and test the channel during the evaluation rather than after signature. Ask who runs the system on the day after hypercare ends - your team, the partner, or an arrangement nobody has defined yet. And ask what happens if the named people leave: a firm that answers that specifically has thought about it, and a firm that answers it reassuringly has not.
One consequence worth stating plainly. If the honest assessment is that neither platform has the local capability your program needs on your timeline, that is a reason to change the timeline or the scope - not a reason to pick the platform with the better brochure. We have recommended delay on exactly this ground.
We publish no month count for either platform, and we would treat one you are offered before anyone has looked at your master data as a negotiating position rather than an estimate. What is both true and useful is the relationship: on comparable scope a NetSuite implementation is typically the shorter of the two, the gap narrows as operational complexity rises and widens as entity count rises. But scope, not platform, is what sets the date.
These are the things that actually move a timeline, in the order we see them bite.
The state of your master data. Customers, suppliers, items, chart of accounts. This is the single most common cause of a slipped go-live in our experience, and migration is priced by how bad the data is rather than by how much of it there is. Look at it in the first week; it is the most reliable predictor of whether the date you are being promised is real.
The number of legal entities, and whether they share a chart of accounts. The second entity is routinely assumed to cost a fraction of the first. That is true when it is genuinely similar and badly wrong when it is not.
The number of integrations, and how cooperative the other side of each one is. An interface into a system whose owner has no capacity for your project is a schedule risk regardless of the technology on either end.
How quickly decisions get made. A program that needs a process dispute settled and has nobody empowered to settle it will drift. That is a governance property, not a technology one, and no platform choice repairs it.
Whether your own people are genuinely available, or are doing the project on top of their real jobs. This factor is larger than all of the above, and it is the one no vendor will raise with you, because it is about you rather than about them.
A useful discipline when you are holding two proposed timelines: ask each vendor which of those five they have assumed, and in what state. The proposal that has assumed clean data and full-time business availability is not faster - it is less honest about the same project.
These are the circumstances in which we recommend NetSuite, stated specifically enough that you can tell whether you are in them.
Choose NetSuite if you are a multi-entity group whose complexity is financial and organizational rather than industrial. Several legal entities, intercompany transactions, more than one currency, and a consolidation currently assembled by hand in a spreadsheet nobody fully trusts. This is the most common correct NetSuite case in this market, and the argument is simple: multi-subsidiary consolidation is core to the product rather than configured on top of it, so you are buying a solved problem rather than a project.
Choose NetSuite if your operational core is order-to-cash, inventory or service delivery rather than production. Distribution, wholesale, retail back-office, professional services and project-based services all sit inside the suite's native span, and the integration work between finance and operations disappears because it was never two systems.
Choose NetSuite if you need a working, compliant set of books inside one budget cycle. Where a regulatory, audit, investor or transaction deadline sets the date, speed to value is not a soft preference - it dominates. The standardized cloud implementation is the shorter path, and choosing the platform that can hit a real date is a legitimate criterion rather than a compromise.
Choose NetSuite if you do not have, and do not want to build, a standing internal ERP capability. If the honest answer to "who runs this platform in-house" is one capable administrator and an empowered finance owner, the vendor-managed upgrade model is worth a great deal. You are buying your way out of an operational responsibility, and that is a real saving that never appears on a cost comparison.
Choose NetSuite if you are growing by adding entities, locations or countries rather than operational depth. Breadth is the direction the suite absorbs most cheaply, and a group that will look the same but larger in five years is in the best possible position to buy it.
Choose NetSuite if your existing estate is already a mix of cloud applications. The integration patterns are well-trodden, the operating model is familiar to your team, and the cultural change the program has to carry is smaller.
The Oracle NetSuite ERP page covers what we deliver on the platform and the shape of a typical program.
This is the section that makes the page worth publishing. We can deliver either platform, so the only thing that makes this comparison useful to you is that it contains real conditions under which we recommend against the answer that would otherwise be our default. Here are those conditions, and they are not hedged.
Choose SAP S/4HANA if you manufacture at depth. Multi-level bills of material, production planning against constrained capacity, shop-floor execution, batch or serial traceability carried as a regulatory obligation, quality management integrated into production rather than bolted beside it. This is what the platform is built for and there is no cheaper way to get it. An organization with this profile that buys the lighter suite will spend the saving twice over on extension work and will still be running a system that is fighting its own design.
Choose SAP S/4HANA if your supply chain is the business. Complex planning, multi-echelon distribution, demand and supply matching at industrial scale, maintenance regimes on physical assets. Depth in these domains is the platform's core proposition, and organizations that genuinely need it tend to recognize themselves in this paragraph immediately.
Choose SAP S/4HANA if you already run SAP and run it well. An existing estate, in-house skills, an established governance model and a group standard are a real asset. Introducing a second platform alongside a working one buys you an integration problem and a second capability to maintain, and that trade has to clear a high bar. It frequently does not.
Choose SAP S/4HANA if your industry's process depth is the requirement. Chemicals and pharmaceuticals, oil and gas, utilities, automotive, large-scale engineering and construction, and the regulated public-adjacent sectors all carry process and compliance requirements the platform addresses directly and that a general-purpose suite would have to be built toward, at your expense and on your timeline.
Choose SAP S/4HANA if your deployment is genuinely constrained. Where a contractual, regulatory or sovereignty requirement dictates where the system runs and who operates it, the ability to choose a deployment model is not a feature - it is the qualifying condition, and a cloud-only product cannot meet it at any price.
Choose SAP S/4HANA if you are large enough that its capability assumption is already true. An organization that already carries an internal systems function, an architecture practice and a governance cadence is not being asked to build anything new. The standing cost that makes the platform heavy for a mid-market company is, for that organization, a cost it is already paying.
Two honest cautions on this side of the table. First, buying the depth without needing it is the most expensive mistake available in this comparison, and it is usually made in good faith by organizations who have been told their complexity is inherent when a good deal of it has simply accumulated. Second, the implementation partner matters more here than on the other side, because there is more to get wrong - which makes section 3.5 a scored criterion rather than a formality. The SAP S/4HANA page sets out what we deliver on the platform.
A meaningful share of the organizations that run this comparison should not be choosing between these two platforms at all. No vendor-funded page will tell you that, which is precisely why it belongs here. There are five such cases, and they are more common than the search traffic for this comparison suggests.
You are a tier too high. A single entity with contained transaction volume, no manufacturing, and a requirement that is really accounting, invoicing, VAT and e-invoicing compliance does not need either of these platforms. An accounting platform solves it at a fraction of the cost and the effort. The tell is a requirements list that describes today's workarounds translated into software language. Our best ERP for Saudi companies guide sets out the tiers and which one your profile actually sits in.
Your core process is the whole business. Multi-location retail and hospitality, construction, healthcare, logistics: an industry-specific system frequently delivers the core process out of the box, and the right architecture is that system alongside a lighter finance platform rather than a general-purpose ERP configured for a year to imitate it. In retail and hospitality especially, the point-of-sale and stock decision comes first and the finance system is downstream of it.
The problem is a process, not a product. If month-end runs long because four teams maintain their own version of the same data and nobody owns the reconciliation between them, a new platform inherits that and adds a migration to it. The cheapest ERP implementation is the one you correctly postponed while you fixed the thing that was actually broken.
The real question is your contract, not your software. Where the incumbent is adequate and the genuine grievance is price, support quality or a module nobody was trained on, replacement is the most expensive available response to a commercial problem. A structured evaluation frequently ends in a renegotiation instead, and that is a legitimate outcome we reach regularly.
The decision is really about data and integration. If the pain is that three systems disagree, replacing one of them changes which three disagree. Integration architecture, data ownership and a single agreed definition of each master record are the work - and they are the work whichever platform you end up on.
If one of those describes you, the useful next step is not a product demonstration. It is a scoped look at what is actually failing, which is what the next section covers.
A comparison page can frame a decision. It cannot weight criteria it does not know about, and yours are specific to your entity structure, your existing estate, your sector and your timetable. Turning this framing into a defensible decision is a piece of work, and this is how we run it.
Criteria first, products second. We write and weight the evaluation criteria with you, and you sign them off, before either product is scored. Criteria written after the candidates are known tend to describe the candidate the author already preferred - which is how a selection reaches a predetermined answer while looking rigorous throughout. Sequencing is the single most effective safeguard in the whole exercise, and it costs nothing.
Your scenarios, your data. Both vendors are given the same scripted scenarios, built from your processes and run against a sample of your own records, and are scored on the same sheet by the same people. A vendor demonstration is a sales exercise, and usually a good one: it shows the best path through a product with clean data, which is not evidence about your case.
The full cost, on one template. Both proposals are normalized onto a single five-year model containing the lines section 3.1 lists, with the same growth assumptions applied to each. This is where close-looking quotations usually separate.
A written recommendation, with the conditions that would reverse it. You get a scored comparison, a recommendation, the assumptions behind it, and an explicit statement of what would have to be true for the other answer to win. A recommendation you cannot invert is a preference, not an analysis.
And a genuine third option. If the evaluation concludes that your incumbent is adequate, that a tier down is the right answer, or that the purchase should wait a year, that is what the report will say. How we evaluate impartially describes the method in full, including how conflicts are declared and how criteria are locked before scoring begins. ERP selection consulting covers the wider engagement - selection, implementation oversight, and the recovery work that begins after a program has already gone wrong.
Fees for both are not published yet - ask, and you will have them before you speak to anyone - and how we work sets out where a selection sits among the stages of an engagement.
The honest answer has two halves, and the second is the one that should matter to you.
First, the disclosure. We are a delivery firm as well as an advisory one. We work with both platforms on this page and can implement either, which means we have a commercial interest in this decision that a pure research house does not. We hold no reseller or distribution agreement for either product and earn nothing from which licence you buy - but implementation services revenue is an interest in its own right, and pretending otherwise would be the fastest possible way to lose your trust. Assume the same is true of almost every firm publishing a comparison like this one, whether or not they say so.
Second, what is done about it, because a disclosed interest is manageable and a denied one is not. The criteria are written and weighted with you and signed off by you before either product is scored. The "choose the other one" conditions are published on this page, in sections four, five and six, rather than kept for a meeting. The evaluation is charged as a fixed fee agreed before scoring begins, so what we earn from the evaluation does not depend on which way it goes. Every recommendation ships with the conditions that would reverse it. And "keep what you have" and "buy a tier down" are outcomes we reach and record as outcomes, because they are.
Third, what you should require - of us and of everyone else. Ask, in writing, before the engagement begins, what the adviser earns under each possible outcome of the recommendation, and require the answer as a clause in the engagement letter rather than as a reassurance in an email. That is the correct question to put to any firm that both advises on and delivers enterprise systems. If you would rather the selection were run by someone with no delivery capability at all, say so - there are cases where that is the right call, and we will tell you plainly when yours is one of them.
This page is written to stay true rather than to stay fresh, which is a deliberate and slightly unusual choice. Everything on it describes structural characteristics - what each platform is built for, where its depth lies, how its cost and upgrade models behave, what its implementation assumes of you - because those change on a scale of years. It carries no version numbers, no release names, no feature ticks, no prices and no compliance statuses, because those change on a scale of weeks, and a page carrying them is wrong long before anyone notices.
That is also the honest answer to the question behind the question. A feature comparison published on any date is out of date for your decision, because your decision is being made now and against your scope. So use this page for the shape of the decision, and verify the specifics that will carry weight against each vendor's current documentation, against ZATCA's own published list of compliant solutions for the e-invoicing question, and above all against your own scripted scenarios run on your own data. If something here reads as out of step with what a vendor is telling you today, tell us - we would rather correct the page than defend it, and a comparison that cannot be corrected is a brochure.
We publish no aggregate figure here - no count of selections run, no share of programs delivered on time, no average saving, no satisfaction score. Not because there is nothing to say, but because a number of that kind is unverifiable by you, is produced by the firm it flatters, and would refute the argument the rest of this page spends fifteen sections making. A buyer evaluating advisers should discount such figures wherever they appear, this page included.
What we will do instead is both more useful and more checkable. In a first conversation we will describe comparable engagements in enough detail for you to judge the fit - sector, entity structure, scope, what the evaluation concluded, and whether that conclusion held afterwards - and where the client permits it we will put you in touch with them directly. Where confidentiality prevents naming an engagement we say so, rather than anonymizing it into a claim you cannot test. Our published, client-approved work is on the success stories pages.
The organizations that bring us this particular comparison are recognizable by shape rather than by name. Multi-entity groups in the Kingdom that have outgrown accounting software and need a consolidation they can defend to an auditor. Manufacturers and engineering firms testing whether their operational complexity genuinely requires an enterprise process platform or has accumulated around processes nobody has revisited in years. Distribution and services businesses that have started reconciling between systems rather than within one. Subsidiaries of international groups holding a mandated group standard against a local requirement it does not fit. And organizations partway into a program that has stopped going well, asking whether the platform was the mistake - where the answer, more often than not, is that it was not.
We do not publish a client list on this page. The organizations that have agreed to be named appear on our customers page, which is maintained with their permission rather than assembled to support a comparison article.
Our published project work lives on the success stories pages, where each entry is a real engagement whose client has approved the account of it. We deliberately do not write case studies for a comparison page: a case study assembled to support an argument is not evidence, it is illustration - and on a page arguing that you should discount claims whose author has an interest in them, publishing one would be self-refuting.
If you want project evidence specific to your decision, ask for it in the first conversation and be precise about what would actually persuade you: the same sector, the same entity structure, the same platform, the same problem, a reference call. That is a reasonable thing to require of us and of everyone else you shortlist, and a firm that cannot meet it on the platform it is recommending has told you something important.
We do not publish a client quote until the client has reviewed and approved the exact wording attributed to them, so this section will carry real, attributed testimonials from ERP selection engagements as those approvals arrive - rather than a composite, a paraphrase, or a quotation drafted in-house and signed off in passing. A quote assembled by the firm it praises is worth precisely nothing, and putting one on this page in particular would quietly contradict every other section of it.
References matter to a decision of this size, and they should. Ask in the first conversation and we will connect you with a comparable client wherever confidentiality permits - which is more useful than a published sentence in any case, because the questions worth asking are about what happened in the ninth month after go-live, and those get answered in a conversation rather than in a pull quote.
On a page that asks you to discount claims from authors with an interest in the outcome, our own interests belong in plain sight rather than in a footnote. We work with both platforms named here and can deliver either, and we hold technical relationships and certifications with a number of enterprise technology vendors. We hold them for one reason: advising on a platform without people who have actually worked inside it produces advice that reads well and fails in delivery.
Three rules govern how that interacts with this comparison, and each is something you can hold us to. Our evaluations are not restricted to products we work with - a shortlist confined to a partner directory is a catalogue wearing the clothes of an evaluation. Where a relationship exists with a vendor under consideration, it is disclosed at the point of the recommendation rather than left for you to discover afterwards. And no vendor sees, funds, reviews or approves this page or any evaluation before it reaches you; none of them has editorial input of any kind.
Our current certifications and technology partner network are published on the partners page. If you want to know whether a particular relationship influenced a particular conclusion, ask - and you will get a direct answer.
This page settles a shortlist of two. The pages around it answer the questions that sit on either side of it. Oracle NetSuite ERP and SAP S/4HANA set out what we deliver on each platform and the shape of a typical program. If you are not yet sure this pairing is the right one, best ERP for Saudi companies works from your profile down to a tier before naming anything, and our other comparisons cover the pairings on either side of this one.
On the advisory side, How we evaluate impartially is the method behind the criteria in section three, and ERP selection consulting covers what happens after the decision - implementation oversight, optimization, and recovery when a program has already stalled. Enterprise systems integration covers the part that most often decides whether a correctly chosen platform succeeds. How we work shows where a selection sits in an engagement, and what each piece costs is not published yet - ask, and you will have it before you talk to anyone.
The comparison above is the general shape. Yours has a specific entity structure, a specific existing estate, a sector, a timetable and a set of constraints that no published page can weight. Tell us three things - what you run today, what is actually failing, and what has to be true a year after go-live - and that is enough for a first conversation and enough for us to tell you whether you need a full evaluation, a smaller piece of work, or nothing at all.
What that conversation will not be is a product pitch. We do not sell you a licence and we earn nothing from which platform you choose, which is what makes it possible for us to tell you that your current system is adequate, or that the purchase you are planning should wait a year, or that the shortlist you arrived with is the wrong shortlist. Those are conclusions we reach regularly and they cost us nothing to say - which is rather the point of being paid by you and by nobody else.