Run honestly, this comparison is a pair of nested decisions wearing the name of one. Neither "SAP" nor "Dynamics 365" is a single product. SAP publishes S/4HANA in a public cloud edition and a private cloud edition with materially different degrees of standardization, and Microsoft publishes Dynamics 365 as a family of applications in which the ERP question splits again. The organizations that get this choice right resolve the inner decision on each side before they score the outer one.
SAP S/4HANA is presented by SAP as the foundational application of SAP Cloud ERP - a modular ERP solution designed to bring built-in AI to core business processes, built on a high-speed database, shipping business processes that incorporate industry-standard best practices. Microsoft Dynamics 365 is documented by Microsoft as a family of business applications, and the ERP decision inside it - Business Central, or the finance and operations applications - comes before any decision against SAP.
The title of this page names the real axis. SAP's public edition is published as highly standardized: you adopt its preconfigured processes and gain their rigour. Microsoft's family is assembled application by application: you gain configurability and carry the assembly. Neither is a virtue in itself - each is a bet on whether your processes should bend to the system or the system to your processes.
Our interest, stated before the argument rather than after it. We work with both platforms and can deliver either. That is a commercial interest in your decision and you should have it now rather than find it on a partners page afterwards. We hold no reseller or distribution agreement for either product and earn nothing from which licence you buy - but implementation revenue is an interest in its own right. 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 enterprises running this comparison, the honest first answer is to resolve the choice inside each name before scoring the pair. On the SAP side: SAP documents both public and private deployment options - the public edition a highly standardized public cloud solution covering selected line-of-business and industry scenarios with a comprehensive ERP scope, the private edition based on standardized business processes but with the extensibility and geographical reach of SAP's on-premises solution. On the Microsoft side: Business Central and the finance and operations applications are documented as separate lines with different design centres and different deployment models. A scorecard built before those two inner choices are fixed produces a confident answer to an unasked question.
Choose SAP S/4HANA when you want the process standard imposed, and you mean it. SAP publishes preconfigured processes incorporating industry-standard best practices as a core of the offer. An organization that intends to adopt a standard rather than negotiate with one - and whose leadership will hold that line when a department asks for an exception - is buying exactly what the vendor says it is selling.
Choose Dynamics 365 when the decision is really an estate decision. If your identity, productivity, data platform and the reporting layer your finance team actually uses are already Microsoft, the pull is real and it is not irrational: a platform decision made once has consequences for every integration afterwards. The configurability the title names is also a genuine property of a family documented app by app - the capability you want may be a different application rather than a customization.
Choose neither yet if you cannot state, in one sentence each, which edition of S/4HANA and which Dynamics 365 application you are comparing. That is section 6. A recommendation you cannot invert is a preference wearing the clothes of an analysis, so every condition on this page is written so that you can tell whether you are in it.
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. Every row below is drawn from the named vendor's own current published documentation and nothing else. Rows we could not source that way were removed rather than estimated, and section 8.2 lists them by name. Verify anything here that will carry weight in your decision against each vendor's current documentation and against your own scripted scenarios.
| Dimension | SAP S/4HANA | Microsoft Dynamics 365 |
|---|---|---|
| What the vendor says it is | The foundational application of SAP Cloud ERP - a modular ERP solution designed to bring built-in AI to core business processes, built on a high-speed database | A family of business applications documented app by app, spanning ERP and customer-engagement lines rather than a single product |
| The choice inside the choice | An edition decision: SAP documents public and private deployment options with different degrees of standardization | An application decision: Business Central, or the finance and operations applications |
| Documented design centre of each inner option | Public edition: a highly standardized public cloud solution covering selected line-of-business and industry scenarios using a comprehensive ERP scope. Private edition: standardized business processes plus the extensibility and geographical reach of the SAP S/4HANA on-premises solution | Business Central: common business processes in small and medium-sized companies, mainly wholesale and professional services, with assembly, manufacturing, service and directed warehouse management also supported. The finance and operations applications: a separate line with its own deployment and licensing model |
| Deployment options the vendor documents | Public cloud edition; private cloud edition; and an on-premises solution whose extensibility and geographical reach the private edition is documented to include | Cloud or on-premises for the finance and operations applications; on-premises is documented as unsupported on public cloud infrastructure including Azure, and supported on Azure Stack HCI and Azure Stack Hub |
| Commercial structure, as published | A subscription model, allowing businesses to scale and adapt the system based on their needs and the amount of flexibility they want | Volume licensing is documented as available to organizations with 250 or more Dynamics 365 users, through an Enterprise Agreement, an Enterprise Agreement Subscription, an Enrollment for Education Solutions, or the Microsoft Products and Services Agreement |
| Industry process content, as published | Ships business processes that incorporate industry-standard best practices, through preconfigured processes | Row not built on this side: no equivalent single published statement was located in Microsoft's cited documentation, and describing it from a third party would breach this page's sourcing rule. That is a gap in our sourcing, not a finding about the product |
| Saudi e-invoicing (ZATCA) | Neither vendor's documentation cited here makes a ZATCA claim, and this page makes none on their behalf. ZATCA's own position is the one that governs: taxpayers may choose any e-invoicing solution provider as long as it is compliant with the e-invoicing requirements, and ZATCA considers the taxpayer compliant where the requirements are met even where the provider is not on ZATCA's indicative list. The obligation sits with you, not with a vendor badge. See section 3.3 | |
Read that table as a shape rather than a scoreboard. Nothing in it says one platform is better. Every row says the two are organized around different assumptions about what you are buying.
Six criteria decide this comparison in Saudi Arabia, and only one of them is functional. They are set out in the order they usually settle the decision rather than the order a feature matrix would put them in.
This section carries no price, licence fee, day rate or range, for two reasons and both are stated plainly rather than worked around. Neither vendor publishes a Saudi-market figure we could cite to its own documentation, and our own fee ranges are not published yet - ask, and you will have it before you talk to anyone. We publish no price for either platform and no comparative figure between them.
What this section can do honestly is name the lines that belong in the model, so that two proposals can be compared on one template rather than on headline numbers:
This is the axis the page is named for, and both vendors publish their side of it plainly. SAP publishes the public edition as highly standardized - the scaling story is adopting a comprehensive ERP scope of preconfigured processes - and publishes the private edition as adding the extensibility and geographical reach of its on-premises solution. So on the SAP side, "customization" is largely an edition selection made up front. Microsoft's family is documented app by app, which means the extension story is partly an application-selection story - the capability you want may be a different app rather than a customization - and Microsoft's Business Central documentation is explicit that standard configurations are expected to be changed to suit the business.
The practical test, which no vendor page will run for you: take the three processes you are least willing to change, and establish for each whether it is configuration, supported extension, or a genuine modification - on both platforms, in writing, before you sign anything. On this pairing, add a fourth question on the SAP side: which edition does the answer assume, and what does the same answer cost in the other edition.
This is the section where comparison pages most often invent a fact, so this one states only what the regulator publishes.
ZATCA implements e-invoicing in two phases. Phase One, the Generation Phase, was enforced from 4 December 2021 for all resident taxpayers and any party issuing tax invoices on behalf of suppliers subject to VAT; invoices are issued through a compliant electronic solution and carry additional fields depending on the transaction type. Phase Two, the Integration Phase, is enforceable from 1 January 2023 in waves; in this phase the electronic solution must be integrated with ZATCA's systems and e-invoices must be generated in the required format.
And the point that reframes the whole question: ZATCA publishes an indicative list of solution providers that have passed its qualification process, but states that taxpayers may choose any e-invoicing solution provider as long as it is compliant with the requirements, and that ZATCA will consider the taxpayer compliant where the requirements are met even if the provider is not on that list.
So the question is never whether an ERP carries a badge. It is: which component in your architecture generates the compliant document and holds the integration to ZATCA's systems, who owns that component when the requirement moves, and what happens to it at your next upgrade - and on this pairing, what happens to it under each edition and deployment model you are actually considering. We do not state either vendor's current compliance status, and you should treat any page that does with caution. Establish it directly with each vendor and against ZATCA's own published list of compliant solutions before it carries weight in your decision.
Microsoft documents Dynamics 365 as a family of business applications spanning ERP and customer-engagement lines. An organization whose identity, productivity, data platform and reporting layer are already Microsoft is therefore making a narrower integration decision than the comparison implies. That is a legitimate advantage and it should be weighted - but weighted as an integration advantage, tested against your actual interfaces, not accepted as a general truth.
The counter-consideration is the standard itself. An estate that adopts SAP's preconfigured processes across its scope is buying coherence the same way a single-suite buyer does: a process that arrives integrated is one you do not reconcile later. Which claim wins is not decidable in general - it is decidable against your interface list.
Test it rather than argue it. List every interface the new platform must carry on day one - the e-invoicing integration first, because in the Kingdom it is the one that cannot slip - and for each one establish on both platforms who builds it, who owns it, what it does at upgrade, and what it costs to keep. That list decides this criterion, and it is different for every organization.
We publish no count of certified consultants, partners or available resources in the Kingdom for either platform. No such figure is published by either vendor in a form we could cite, and a number of that kind invented for a comparison page is exactly the sort of claim this cluster exists to argue against.
What to do instead, which is more useful anyway: require named individuals in the proposal rather than a capability statement, ask what happens to that team when the implementation ends, and ask both vendors' local organizations directly what support you are entitled to under the agreement you are being offered. A firm that cannot name the people who will do the work has answered the question.
Neither vendor publishes an implementation duration for either platform in the documentation cited here, so this page publishes none. We publish no month count for either platform. Any number in a comparison page is a fitted answer to a scope nobody described.
What actually moves the duration, on either platform, and what you can therefore control: the number of legal entities in wave one; the number and cleanliness of the data sets you migrate; the number of integrations that must be live at cutover; how many processes you are unwilling to change - which on the SAP public edition is close to the whole question; and whether the decision rights in your organization are held by someone who can exercise them.
Ask both bidders for a plan with those five inputs stated as assumptions, and compare plans rather than durations. A bidder who will not state the assumptions has not given you a date.
Written to be invertible. Each condition is specific enough that you can tell whether you are in it.
This is the section that makes the page worth publishing. If it reads weaker than section 4, the page has failed - because 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.
If none of those five is true of you, section 4 is probably your answer - and if two or more are, this one is.
Three cases, and in this pairing the first is the most common outcome we actually reach.
You have not resolved the choice inside either name. Which S/4HANA edition, and which Dynamics 365 application, are prior questions with different answers for cost, deployment, extensibility and upgrade behaviour - each vendor's own documentation says so. Until both are fixed, you are running a four-way comparison with two columns, and any scorecard you produce will be confidently wrong.
Your problem is not an ERP problem. A material share of the organizations that arrive at this comparison are describing a reporting problem, a process-ownership problem or a data-quality problem. None of those is solved by replacing the ledger, and all three follow the data into whichever platform you buy. ERP selection consulting covers that diagnosis.
You are not the tier this pairing serves. This is the enterprise end of the market on both sides. If Business Central's documented design centre reads like your organization, or you are consolidating a mid-market group, Best ERP for Saudi companies works from your profile down to a tier before naming any product, NetSuite vs Dynamics 365 covers the pairing one tier down, and NetSuite vs SAP S/4HANA covers the suite-versus-process-platform question from the other direction.
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. This is how we turn the framing into a defensible decision.
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.
The choice inside each name is resolved before the pair is scored. On this pairing specifically, the SAP edition decision and the Microsoft application decision are settled explicitly and recorded, so that what gets scored is two comparable things.
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 scored on the same sheet by the same people. A vendor demonstration 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 multi-year model containing the lines section 3.1 names, with the same growth assumptions applied to each. This is where close-looking quotations 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.
And a genuine third option. If the evaluation concludes that your incumbent is adequate, that a tier down is right, 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.
Fees for both are not published yet - ask, and you will have it before you talk 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. 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. Everything on it describes structural characteristics - what each vendor publishes its product to be, how the family is organized, what deployment and licensing structures are documented - 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.
It also carries a rule the rest of the market does not publish: every claim on this page about a product we do not make is taken from that vendor's own current documentation, and any comparison point we could not source that way was removed rather than estimated. Several conventional rows are missing from section 2 for exactly that reason - implementation durations, partner and consultant counts in the Kingdom, feature-level parity claims, any price, any market-share or deployment-count claim, and an industry-process-content row on the Microsoft side. Their absence is deliberate. A comparison that fills those rows from memory is the thing this page exists not to be.
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.
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. 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. Groups whose estate standardized on Microsoft everywhere except the ledger, deciding whether the ledger should follow. Industrial and process businesses testing whether the standardized scope SAP publishes actually covers them, or covers them at the cost of processes they regard as their edge. Subsidiaries of international groups holding a mandated group template - often an SAP one - 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 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.
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. Ask in the first conversation and we will connect you with a comparable client wherever confidentiality permits.
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. 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.
Our current certifications and technology partner network are published on the partners page.
This page settles a shortlist of two. The pages around it answer the questions on either side of it. SAP S/4HANA and Microsoft Dynamics 365 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, NetSuite vs SAP S/4HANA and NetSuite vs Dynamics 365 each hold one of this page's products against the suite alternative, and our other comparisons index the rest.
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. 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.