Saudi Arabia's ERP market is growing at 15.2% annually and is projected to reach USD 1.6 billion by 2033, driven by Vision 2030 and an accelerating wave of regulatory mandates. For businesses in Riyadh, Jeddah, and across the Kingdom, that growth brings a compliance deadline alongside it.
Deploying Microsoft Dynamics 365 in Saudi Arabia is not the same as deploying it anywhere else. ZATCA e-invoicing, Arabic right-to-left configuration, Saudisation tracking, and VAT reporting are not optional enhancements. They are non-negotiable requirements that must be scoped from day one.
The real risk for IT managers and operations directors is not choosing the wrong platform. It is underestimating the customisation scope and paying for rework mid-project.
Why Customisation in Saudi Arabia Is Different from a Standard D365 Project
A standard Dynamics 365 implementation in most markets focuses on process mapping, data migration, and module configuration. In Saudi Arabia, that baseline work is still required, but it sits underneath a second layer of mandatory localisation that is entirely unique to the Kingdom.
That second layer includes:
- ZATCA Phase 2 e-invoicing integration with the Fatoora government platform
- Arabic UI and right-to-left interface configuration across all customer-facing modules
- Saudisation (Nitaqat) ratio tracking within HR and payroll
- Saudi VAT at 15% with GAZT-compliant reporting
- Hijri calendar support for internal and external documents
- Bilingual document outputs in Arabic and English
None of these are add-ons you can defer to a later phase. Saudi regulatory bodies enforce compliance at the point of operation, not at a convenient future date. Businesses in Riyadh and Jeddah, where the majority of ERP deployments are concentrated, face the highest audit and inspection frequency.
What this means in practice: your Dynamics 365 project in Saudi Arabia will require more scoping time, more configuration work, and more testing cycles than an equivalent project in Europe or North America. Budget and timeline assumptions from previous implementations in other markets will not hold.
ZATCA Phase 2: The Non-Negotiable Customisation Every Saudi Business Needs
ZATCA (the Zakat, Tax and Customs Authority) mandated e-invoicing in two phases. Phase 1 required businesses to generate electronic invoices. Phase 2, known as the integration phase, requires those invoices to connect directly to ZATCA's Fatoora platform in real time. This is where most Dynamics 365 projects in Saudi Arabia encounter their most complex technical requirement.
Who Must Comply and When
The Phase 2 rollout is wave-based, targeting businesses by annual VAT revenue:
- Businesses with VAT revenue of SAR 7 million or more were required to integrate by January 2025
- Businesses with VAT revenue above SAR 375,000 must complete Fatoora integration by 30 June 2026
- All VAT-registered businesses will ultimately fall within scope
If your organisation is in Riyadh or Jeddah and has not yet mapped this into your Dynamics 365 roadmap, the deadline is closer than most project timelines allow.
What the Integration Actually Requires
ZATCA Phase 2 is not a reporting export. It is a live API connection between your Dynamics 365 environment and the Fatoora government platform. The technical requirements are specific:
- XML invoice format: every invoice must be generated in UBL 2.1 XML format, structured to ZATCA's published schema
- QR code generation: each invoice must carry a ZATCA-compliant QR code encoding seller details, VAT number, invoice total, and VAT amount
- Cryptographic stamp: invoices require a digital signature applied at the point of generation, not retrospectively
- Real-time clearance: B2B invoices above the threshold must be submitted to Fatoora for clearance before being sent to the buyer
- Reporting invoices: B2C invoices must be reported to ZATCA within 24 hours of issuance
How Dynamics 365 Handles This
Microsoft's localisation documentation for Saudi Arabia confirms that Dynamics 365 Finance supports ZATCA Fatoora connectivity through built-in localisation features. The critical implementation advice from Microsoft is to use the standard configuration rather than building custom ZATCA flows. Customising core Phase 2 processes introduces compliance risk and significantly increases testing overhead.
The implementation risk: partners who build bespoke ZATCA integrations instead of leveraging the standard Microsoft localisation layer expose their clients to compliance failures when ZATCA updates its schema or tightens its validation rules. Use the standard. Configure it correctly. Test against ZATCA's sandbox environment before go-live.
Arabic Language and Right-to-Left Interface Configuration
Arabic is not just a display setting in Dynamics 365. It is a configuration workstream that touches every module where documents, reports, or user interfaces are customer-facing or regulatory-facing.
Dynamics 365 Finance and Supply Chain Management include native Arabic UI and right-to-left support. However, that support must be activated and tested across the full scope of your deployment. Language-specific templates for invoices, purchase orders, delivery notes, and statements of account need to be configured during the initial setup phase, not added retrospectively.
What to Configure
- RTL interface: enable Arabic UI across all relevant modules at the tenant level; spot-testing one module is not sufficient
- Bilingual document outputs: customer-facing documents in Saudi Arabia are typically required in both Arabic and English; configure dual-language templates for invoices, credit notes, and delivery documents
- Hijri calendar: Saudi Arabia uses the Hijri calendar for official documents; Dynamics 365 supports Hijri date formatting but it must be explicitly configured per document type
- Arabic chart of accounts: localise account names and financial reporting labels to meet Arabic-language audit requirements
The Business Central Exception
If your organisation is evaluating Microsoft Dynamics 365 Business Central rather than Finance and Operations, note that standard Business Central does not include Arabic RTL support out of the box. Arabic configuration for Business Central requires a custom solution or a localised extension. This is a material difference in scope and cost that should be clarified at the evaluation stage, not discovered during implementation.
Treat Arabic and RTL as a core workstream, not a cosmetic setting. Late scoping of language requirements is one of the most common causes of go-live delays in Saudi Dynamics 365 projects.
Saudisation (Nitaqat) Compliance in HR and Payroll Modules
Saudi Arabia's Nitaqat programme sets mandatory localisation quotas, requiring businesses to maintain a minimum ratio of Saudi nationals to expatriate workers. The 2026 Nitaqat phase targets the localisation of 340,000 jobs across multiple sectors, with enforcement tied directly to a business's ability to access government services, renew licences, and sponsor work visas.
For Dynamics 365 HR and payroll implementations, Nitaqat compliance is not a reporting afterthought. It requires the system to actively track, calculate, and report Saudi-to-expat ratios at the entity and department level.
What Dynamics 365 Must Support
- Saudi national ratio tracking: real-time visibility of Nitaqat band status (Platinum, Green, Yellow, Red) based on current headcount
- Muqeem and Iqama integration: Dynamics 365 must connect to the Muqeem government platform for visa status tracking and Iqama (residency permit) data; without this integration, HR data exists in a silo that creates compliance gaps
- Wage Protection System (WPS): monthly payroll submissions via the Mudad platform are mandatory; Dynamics 365 payroll must be configured to generate WPS-compliant files
- Hijri date support in HR records: employee contracts, leave entitlements, and official correspondence frequently require Hijri dates
- Bilingual HR documentation: employment contracts and payslips are typically required in both Arabic and English
The Payroll Complexity
Heightened Saudisation targets are driving salary competition for Saudi nationals, which directly affects payroll budgeting and workforce planning. Operations directors in Riyadh and Jeddah consistently report that without accurate headcount and salary data in a single system, Nitaqat planning becomes reactive rather than strategic. Dynamics 365, configured correctly with HR and payroll localisation, gives operations teams the data they need to manage ratio compliance proactively.
VAT Configuration and Saudi Tax Authority Reporting
Saudi Arabia applies VAT at 15%, one of the highest standard rates in the GCC. Dynamics 365 natively supports this rate, but correct VAT configuration goes well beyond entering a percentage. The system must be structured to handle the full Saudi tax reporting cycle accurately.
Key VAT Configuration Requirements
- Tax group setup: configure separate tax groups for standard-rated, zero-rated, and exempt supplies; Saudi VAT applies differently across sectors including healthcare, education, and financial services
- VAT return generation: Dynamics 365 must produce VAT return data in the format required by ZATCA for periodic submission; this includes input tax, output tax, and net VAT liability by reporting period
- Reverse charge mechanism: applicable to certain imported services; the system must handle self-assessment VAT entries correctly
- VAT on intercompany transactions: businesses with multiple legal entities in Saudi Arabia must configure intercompany VAT rules to avoid double-counting or missed reporting
- Audit trail requirements: ZATCA requires businesses to maintain VAT records for a minimum of six years; document archiving and retrieval must be built into the system configuration
The ZATCA Audit Risk
ZATCA has significantly increased audit activity since the introduction of Phase 2 e-invoicing, because the Fatoora platform gives the authority real-time visibility of invoice data. VAT misconfigurations that previously went undetected until a periodic audit are now visible immediately. Getting the VAT configuration right at go-live is not a best practice. It is a risk management requirement.
Industry-Specific Customisations: Manufacturing, EPC, and Oil and Gas
Saudi Arabia's Vision 2030 diversification agenda is driving significant ERP investment across manufacturing, engineering, procurement and construction (EPC), and oil and gas. Each sector carries customisation requirements that go beyond the standard Saudi localisation layer.
Manufacturing
- Bill of materials and production order localisation: Arabic item descriptions, bilingual production documentation, and Hijri-dated batch records
- Quality control integration: Saudi Standards, Metrology and Quality Organization (SASO) compliance tracking within the quality management module
- Landed cost and customs duty: import-heavy manufacturers need customs duty calculation and Saudi customs documentation integrated into procurement workflows
EPC (Engineering, Procurement, and Construction)
- Project Operations module: Dynamics 365 Project Operations is the relevant module for EPC businesses; it must be configured for percentage-of-completion revenue recognition in line with IFRS 15 as adopted in Saudi Arabia
- Subcontractor management: Saudi labour law governs subcontractor relationships differently from international norms; contract and payment workflows must reflect local requirements
- Retention tracking: EPC contracts in Saudi Arabia typically include retention clauses; Dynamics 365 must be configured to hold and release retention amounts correctly against project milestones
Oil and Gas
- Aramco and SABIC vendor compliance: businesses supplying Saudi Aramco or SABIC must meet specific procurement and invoicing standards; Dynamics 365 supplier portals and invoice formats may require customisation to match buyer requirements
- HSE reporting: health, safety, and environment reporting is mandatory for contractors operating on Saudi Aramco and government sites; custom reporting modules or Power BI integrations are typically required
- Foreign currency and hedging: oil and gas businesses operating across currencies need multi-currency configuration with SAR as the functional currency
The common thread across all three sectors: standard Saudi localisation covers compliance. Industry-specific customisation covers competitive differentiation and operational efficiency. Both are required, but they must be scoped separately to avoid scope creep.
How to Avoid Costly Customisation Mistakes
The most expensive Dynamics 365 projects in Saudi Arabia are not the large ones. They are the ones that were scoped incorrectly and required rework mid-implementation. There are four patterns that account for the majority of avoidable cost overruns.
Customising What Microsoft Has Already Solved
ZATCA, VAT at 15%, Arabic UI, Hijri calendar, and bilingual outputs are all supported natively in Dynamics 365 Finance and Supply Chain Management. Building custom solutions for these requirements adds development cost, creates a maintenance burden, and introduces compliance risk every time Microsoft updates the standard localisation layer. The correct approach is to configure the standard features correctly, not to replace them.
Treating Compliance as a Phase 2 Activity
"We will add ZATCA and Arabic in a later phase" is one of the most common and costly decisions made in Saudi ERP projects. Compliance requirements affect data models, document templates, chart of accounts structure, and workflow logic. Retrofitting them after go-live is significantly more expensive than building them in from the start. Scope compliance from day one.
Under-Scoping the Testing Cycle
ZATCA Phase 2 integration requires testing against ZATCA's sandbox environment before production go-live. Arabic RTL configuration requires end-to-end document testing across every template. Nitaqat ratio calculations require validation against real headcount data. Each of these testing cycles takes time. Projects that compress testing to meet an arbitrary go-live date are the ones that face compliance failures in the first month of operation.
Selecting a Partner Without Saudi Localisation Experience
Dynamics 365 implementation experience in other markets does not translate directly to Saudi Arabia. A partner who has not delivered ZATCA Phase 2 integration, configured Muqeem connectivity, or managed a Nitaqat-compliant payroll rollout will learn on your project. That learning has a cost, and it is paid by the client.
Saudi D365 Customisation Checklist
Use this checklist to assess the readiness of your Dynamics 365 customisation scope before committing to an implementation plan. Every item marked incomplete represents a risk to your go-live timeline or compliance status.
ZATCA and E-Invoicing
- Confirmed whether your VAT revenue triggers Phase 2 Fatoora integration (SAR 375,000 threshold)
- Identified the correct Microsoft localisation feature set for ZATCA; not a bespoke build
- Planned ZATCA sandbox testing environment access before production go-live
- Mapped B2B clearance and B2C reporting workflows separately
Arabic and Language Configuration
- Arabic RTL enabled at tenant level across all relevant modules
- Bilingual document templates configured for invoices, POs, credit notes, and delivery documents
- Hijri calendar activated for all document types requiring it
- Arabic chart of accounts localised and validated
VAT and Tax Reporting
- Tax groups configured for standard-rated, zero-rated, and exempt supplies
- VAT return generation tested against ZATCA submission format
- Reverse charge mechanism configured for applicable imported services
- Six-year document archiving policy built into system configuration
HR, Payroll, and Saudisation
- Nitaqat band tracking configured at entity and department level
- Muqeem and Iqama integration scoped and tested
- WPS-compliant payroll file generation configured for Mudad submission
- Bilingual employment contracts and payslips configured
Industry-Specific (where applicable)
- EPC: Project Operations configured for percentage-of-completion revenue recognition
- Manufacturing: SASO quality compliance tracking included in scope
- Oil and Gas: Aramco/SABIC vendor compliance requirements documented and mapped
Requirements and Governance
- Cross-department requirements captured before customisation begins
- Conflicting departmental expectations identified and resolved in scoping
- Implementation partner has confirmed Saudi localisation delivery experience
- Compliance workstreams (ZATCA, Arabic, VAT, Nitaqat) scoped from day one, not deferred
Why Structured Requirements Capture Is Critical Before Any Customisation Begins
The most common cause of expensive customisation rework is poorly captured requirements. When different departments have conflicting expectations about how a process should work, those conflicts surface mid-implementation, at maximum cost.
Finance may expect VAT reporting to work one way. Operations may have mapped procurement workflows differently. HR may have assumptions about payroll that conflict with IT's understanding of the system's capabilities. In a Saudi Dynamics 365 project, where compliance requirements add a mandatory layer of complexity on top of business process requirements, these conflicts are especially costly to resolve late.
Terracez addresses this through Alignyx, a requirements and dependency mapping tool built specifically for complex ERP implementations. Alignyx maps cross-department dependencies and surfaces requirement conflicts before a single line of customisation code is written. Rather than discovering in week eight of a twelve-week project that finance and operations have incompatible expectations about how ZATCA invoices should be approved, those conflicts are identified and resolved in the scoping phase. The result is a customisation scope that reflects what the business actually needs, not what one department assumed, and a go-live that does not require expensive course corrections mid-project.
What Good Requirements Capture Looks Like
- All departments that touch the system are included in requirements workshops, not just IT
- Process owners sign off on workflows before development begins
- Compliance requirements (ZATCA, VAT, Nitaqat) are mapped alongside business process requirements, not in a separate track
- Conflicting requirements are documented, escalated, and resolved before the customisation scope is finalised
- The agreed scope is version-controlled and referenced throughout the project
For businesses in Riyadh and Jeddah managing complex, multi-department implementations, structured requirements capture is not a project management nicety. It is the single most effective cost control measure available before go-live.
Dynamics 365 Costs for Saudi Arabia Projects
Understanding the cost structure of a Dynamics 365 project in Saudi Arabia requires separating three distinct components: Microsoft licensing, implementation services, and Saudi-specific localisation and customisation work.
Microsoft Licensing
Dynamics 365 Finance is priced at approximately USD 180 per user per month for a full licence. Supply Chain Management is similarly priced. Business Central starts at around USD 70 per user per month for the Essentials tier and USD 100 for Premium. These are per-user, per-month subscription costs paid to Microsoft and do not vary based on geography.
Implementation and Customisation Services
Implementation costs in Saudi Arabia vary significantly based on scope, number of users, modules selected, and the degree of customisation required. Realistic ranges for Saudi projects:
- Small business (up to 25 users, standard modules): USD 40,000 to USD 80,000
- Mid-market (25 to 100 users, multiple modules with Saudi localisation): USD 100,000 to USD 300,000
- Enterprise (100+ users, complex customisation, industry-specific requirements): USD 300,000 and above
What Increases the Cost in Saudi Arabia
Saudi-specific requirements add to the baseline implementation cost. The items that most commonly increase scope and budget include:
- ZATCA Phase 2 integration and testing: adds 10 to 20 per cent to the finance module implementation cost
- Arabic RTL configuration and bilingual document templates: adds 5 to 10 per cent depending on the number of document types
- Muqeem and WPS integration for HR and payroll: typically scoped as a separate workstream at USD 10,000 to USD 30,000
- Industry-specific customisation (EPC project operations, oil and gas HSE reporting): highly variable; must be scoped individually
The cost of rework is always higher than the cost of getting it right. A mid-market project that requires significant rework due to missed compliance requirements or poorly captured requirements can easily double its original budget. Structured scoping and a partner with Saudi localisation experience are the most reliable cost controls available.
Regional Support That Understands the Saudi Market
Implementing Dynamics 365 in Saudi Arabia requires more than technical capability. It requires a partner who understands the regulatory environment, has delivered Saudi-specific localisation work before, and can provide ongoing support in the region after go-live.
Terracez operates across the GCC with dedicated presence in Saudi Arabia, supporting businesses in Riyadh and Jeddah through the full implementation lifecycle. As a certified Microsoft Dynamics 365 implementation partner, Terracez brings direct experience with ZATCA Phase 2 integration, Arabic and RTL configuration, Nitaqat-compliant HR and payroll rollouts, and industry-specific customisation for manufacturing, EPC, and oil and gas clients across the Kingdom.
What separates Terracez from a generic implementation partner is how projects are scoped before customisation begins. Alignyx is Terracez's proprietary requirements and dependency mapping tool, used at the start of every Saudi Dynamics 365 engagement to align cross-department expectations, surface conflicts early, and lock down a compliance-ready scope before development starts. For businesses in Riyadh and Jeddah where multi-department implementations are the norm, this structured approach is the difference between a clean go-live and a rework cycle.
What Regional Delivery Means in Practice
- ZATCA expertise: hands-on experience with Fatoora connectivity, XML invoice configuration, and ZATCA sandbox testing; not theoretical knowledge
- Arabic configuration: native-language capability for requirements workshops, user acceptance testing in Arabic, and bilingual training delivery
- Saudi regulatory familiarity: direct knowledge of Nitaqat bands, Muqeem integration, WPS compliance, and ZATCA audit requirements; no learning curve at the client's expense
- Post-go-live support: 24/7 SLA-backed support for Dynamics 365 platforms, with escalation paths that understand Saudi business hours, Arabic-language issues, and local compliance updates
- Requirements workshops in-market: structured scoping sessions delivered in Riyadh or Jeddah, with cross-department facilitation that surfaces conflicts before customisation begins
For IT managers and operations directors who need a partner that has already navigated the Saudi localisation landscape, not one that will navigate it for the first time on your project, regional experience is the most important selection criterion after technical capability.
Start with the Right Scope
Saudi Arabia's regulatory environment makes Dynamics 365 customisation more complex than a standard ERP deployment. ZATCA Phase 2, Arabic configuration, Nitaqat compliance, and VAT reporting are not optional, and they cannot be deferred. The businesses that go live on time and on budget are the ones that scoped these requirements correctly from the start, selected a partner with genuine Saudi localisation experience, and resolved cross-department conflicts before customisation began.
If you are planning a Dynamics 365 implementation or localisation project in Saudi Arabia, the right starting point is a structured assessment of your compliance requirements and customisation scope.
Speak to Terracez about your Dynamics 365 implementation and localisation requirements.




.png)

.webp)