Power BI developer for Saudi Arabia: one set of numbers from your store, POS and accounts

What does a Power BI developer in Saudi Arabia actually build?

A Power BI developer in Saudi Arabia builds three things: a data model that joins your systems, a set of measures that calculate the numbers management argues about, and report pages that show those numbers to the right people at the right time. The visuals are the smallest part of the job.

Most Saudi companies that come to us already have data. The café chain has Foodics. The online brand has Salla or Zid. The trading company keeps its books in Qoyod and its targets in Excel. What they lack is one place where “sales” means the same thing for the owner, the accountant and the branch manager. Today someone downloads three exports on Sunday morning, pastes them into a workbook and emails it round, and by Tuesday nobody trusts it.

The model is where that stops. A Power BI developer decides which table holds orders, how refunds are netted off, whether amounts are shown with or without VAT, how a branch in Olaya is linked to a region, and how a product sold online matches the same product at the till. Once that is agreed, every report page reads from the same definitions.

At BtechWaleTech the work is split across three freelance developers. Another of us leads the data side, from connections and modelling to DAX measures. One of us builds any API pipeline or small web tool the model needs. The third of us runs the plan, the demos and the handover, and checks that each number matches what your accountant already reports.

When is a Saudi company ready for Power BI, and when is Excel still enough?

You are ready for Power BI when the same report is rebuilt by hand every week, when more than one person needs a different slice of it, or when data comes from two or more systems. If one person reads one export once a month, a clean Excel template is cheaper and perfectly fine.

A useful test is to count the hours. If a finance or operations person spends half a day each week copying exports, fixing column names and rebuilding pivot tables, that time alone justifies a model that refreshes itself. The second test is disagreement: if branch managers dispute head office figures, the problem is definitions, and a shared model settles them.

There are also signs you are not ready yet. If the POS has no consistent product codes, if half the sales happen off-system, or if the accounting file is months behind, a dashboard will display the mess faster rather than fix it. In that case the first milestone is data hygiene: agreeing codes, closing the books to date, and deciding which system is the source of truth for each figure.

• Choose Power BI when two or more systems feed one management report.
• Choose Power BI when branch or regional managers each need their own view.
• Stay with Excel when one person reads one monthly export and nothing else.
• Fix the data first when codes, branches or dates are inconsistent at the source.

Connecting Salla, Zid, Foodics and Qoyod data to Power BI

Each Saudi platform offers either an API, scheduled exports, or both, and the right route depends on how often you need fresh numbers. A Power BI developer should tell you, per source, which route is planned and what happens if it fails.

We do not rely on any one-click connector for these platforms. The two dependable routes are: read their APIs through a small pipeline into a staging database, or read CSV and Excel exports dropped into a SharePoint or OneDrive folder that Power BI refreshes from. The first gives fresher numbers; the second is cheaper to start and easy to replace later.

If a source needs an API pipeline, it runs in your own cloud account and is quoted as a small service; the custom software page explains how those builds work.

How a Power BI developer models Saudi sales, POS and accounting data

Good Power BI work in Saudi Arabia starts with a star schema: fact tables for sales lines, payments, invoices and stock movements, surrounded by dimension tables for date, branch, product, channel and customer. That shape keeps reports fast and totals correct.

The hard part is matching. A shawarma wrap sold at the till, the same wrap ordered through a delivery app, and the recipe line in the accounting system may all carry different names. We build a product mapping table, agree it with your operations lead, and give someone on your side a simple sheet to maintain as the menu or catalogue changes.

Branches need the same care. Each one gets a stable code, a city, a region, an opening date and, where relevant, a flag for mall, street or drive-through format. That lets you compare like with like, and it lets new branches sit outside the like-for-like figures until they have a full year of trading.

Measures come last and are written once. Net sales, VAT-exclusive revenue, average ticket, items per order, gross margin and stock cover are defined in DAX with a short description, so a report built next year uses the same logic as the one built today.

Hijri and Gregorian dates in Power BI: building a calendar Saudi managers trust

Build one Gregorian date table and add Hijri columns to it, rather than keeping two calendars. Every fact joins to the Gregorian date; the Hijri year, month and day sit alongside as attributes, so a manager can slice by either.

This matters because the Hijri year is roughly eleven days shorter than the Gregorian year. Ramadan, Eid al-Fitr and Eid al-Adha move earlier every Gregorian year, so comparing “March this year with March last year” can compare a Ramadan month with a normal one. For restaurants, retail and gifting, that comparison is misleading.

We generate the Hijri columns once from an Umm al-Qura conversion table, check them against dates you already know, such as last year's first day of Ramadan, and let your team correct a date if an official announcement differs. We then add flags such as “Ramadan”, “last ten nights”, “Eid week” and “national holiday”, plus a same-period-last-Hijri-year measure.

• Gregorian date, week starting Sunday, month and quarter.
• Hijri year, month number, Arabic and English month names, and day.
• Flags for Ramadan, Eid periods, Saudi National Day and Founding Day.
• Fiscal year columns if your year does not follow the calendar.
• A like-for-like flag per branch, based on its opening date.

SAR amounts, VAT and number formats in Saudi Power BI reports

Decide once whether each report shows amounts with VAT or without, label it on the page, and store both in the model. Arguments between sales and finance usually come from mixing the two.

POS and ecommerce exports often report totals including VAT and after discounts, while accounting reports revenue net of VAT. We keep gross, discount, VAT and net as separate columns, so the operations page can show what customers paid and the finance page can show revenue as your accountant books it. When figures come from invoices that follow ZATCA's e-invoicing rules, the model reads the tax fields rather than recalculating them.

Formatting is simpler. SAR amounts get a consistent format string, thousands separators and no stray decimals on summary cards. You choose Western or Arabic-Indic digits for any Arabic-labelled page; Power BI takes some number and date formatting from the model locale and user settings, so we test pages under the settings your managers really use.

Arabic labels in Power BI reports: what works and what to expect

Arabic text displays in Power BI visuals, slicers and titles, and the Power BI service itself is available in Arabic. What Power BI does not do is mirror a report layout for right-to-left reading, so an Arabic report is a translated report, not a flipped one.

Microsoft's language documentation is explicit on two points. Power BI Desktop, where reports are built, is available in the same languages as the service except Arabic and Hebrew, and does not support right-to-left languages. And inside reports, the layout of visuals does not change when a right-to-left language is used. The same page notes that your data is not translated automatically and that Q&A, the natural-language feature, is available in English only.

In practice we design pages so they read acceptably in either direction: key numbers in cards across the top, charts below, and slicers in a panel that works on either side. For bilingual reports, we either build separate Arabic and English pages from one model or use Microsoft's translations approach for metadata so field and measure names appear in the viewer's language. You supply or approve the Arabic wording; we write English and handle the structure.

Need a bilingual website to sit beside the dashboards? Our Arabic-English website builds use the same “you approve the Arabic” workflow.

Row-level security for branches, regions and area managers

Row-level security lets one report serve every branch while each manager sees only their own rows. It is the feature that makes a single Power BI model workable for a multi-branch Saudi business.

Microsoft's documentation describes the workflow: roles and DAX filter rules are defined in Power BI Desktop, the model is published, and users or security groups are added to roles in the Power BI service. We usually build dynamic security: a small mapping table lists each manager's work email against the branches or region they cover, and a single rule filters data using the signed-in user's name. When someone changes branch, you edit one row instead of republishing the report.

One detail catches many companies out. Microsoft states that row-level security applies only to people with the Viewer role in a workspace; Admins, Members and Contributors can edit the model, so the filter does not restrict them. We therefore keep branch managers as viewers of a Power BI app, keep editors to a short list at head office, and test every role with the “Test as role” option before rollout.

• Branch manager: one branch, all its products and hours.
• Area manager: every branch in the region, with branch comparison.
• Finance: all branches, VAT and cost columns visible.
• Franchise partner: only their outlets, with head-office measures hidden where needed.

How often can Power BI refresh? Scheduling around Saudi trading hours

On shared capacity, which covers most Pro-licensed workspaces, Microsoft limits a semantic model to eight scheduled refreshes a day; on Premium, Premium Per User or Fabric capacity, you can schedule up to 48. Choose the times around when your data actually changes.

Microsoft's refresh documentation adds two limits worth planning for: a refresh on shared capacity must finish in under two hours, and on Premium the maximum is five hours. Schedules follow the time zone set on the model, so we set it to Riyadh time rather than leaving a default. A gateway is only needed if part of the data sits on a machine or network Power BI cannot reach directly, such as an on-premises SQL Server at head office.

For a restaurant group, a sensible pattern is one refresh after the last branch closes, one mid-morning for overnight delivery orders, and a few across the afternoon if managers watch the lunch rush. A store that trades mostly online may prefer an evenly spread schedule. Owners who want minute-by-minute numbers should know that is a different architecture with a higher running cost, and a daily view is enough for most decisions.

Failure alerts go to the model owner by email. We make that owner an account in your organisation, not ours, and we document what to check when a refresh fails.

Which Power BI licences does a Saudi company need?

Anyone who publishes or shares reports needs Power BI Pro or Premium Per User, and on shared capacity anyone who views shared content needs a paid licence too. Free users can view shared content only when it sits in a workspace on Premium capacity or Fabric F64 or larger.

That is how Microsoft's licence page describes it: free users can build reports for their own use but cannot share or collaborate; Pro users share with other Pro users; PPU users share with other PPU users; and capacity workspaces let content reach colleagues on any licence. For a company with a handful of managers, Pro for each of them is usually the simplest answer. Larger groups with many read-only viewers should compare the cost of capacity with the cost of many individual licences.

Licences are bought by you from Microsoft or your usual reseller, inside your own Microsoft 365 tenant. We never resell licences or hold them in our name. During scoping we list exactly who will build, who will view and which features you need, so you buy the right mix rather than guessing.

How to vet a Power BI developer for a Saudi Arabia project

Ask to see a model, not a pretty dashboard. A screenshot hides everything that matters; a ten-minute walk through tables, relationships and measures shows whether the developer thinks about correctness.

Then ask questions that only someone who has worked with Saudi data will answer well. The answers take minutes, and weak ones are obvious.

• How would you compare this Ramadan with last Ramadan when the Gregorian dates differ?
• Where would VAT sit in the model, and which pages would show gross versus net?
• How would a branch manager be restricted to their branch, and who would that rule not apply to?
• What happens to the report if Foodics or Salla changes an export column name?
• Which scheduled refresh times would you set for a business closing at 2 am?
• Whose tenant and whose account will own the workspaces and the refresh?
• How will you prove your totals match the accountant's monthly figures?

A good candidate, including us, should answer all seven in writing before you pay anything. For a wider view on remote hiring, see hiring Indian developers.

How much does a Power BI developer in Saudi Arabia cost?

With BtechWaleTech, a first Power BI project starts from US$600. Market quotes vary widely, and the difference is mostly scope, data quality and overheads rather than the software.

The biggest cost driver is the number and condition of sources. One clean Salla export is quick; Foodics across twelve branches, a Qoyod file with inconsistent cost centres and three budget spreadsheets take longer. Next come the number of security roles, the number of report pages, whether a staging database is needed, and how much training your team wants. A pipeline that reads APIs on a schedule is quoted as a small software build from US$900.

Running costs are separate and predictable: Microsoft licences for the people who need them, and, if we build a pipeline, a small cloud database in your account. After two months of free support, an optional care plan starts from US$120/mo for fixes, new measures and adjustments when a source system changes. Hiring an in-house analyst is the other benchmark; it suits companies with a constant stream of new analysis, not a one-off build.

For comparable figures on software and apps in the Kingdom, the Saudi app development cost guide uses the same starting-price approach.

How long does a Power BI dashboard project take for a Saudi business?

A first dashboard set usually takes two to four weeks from the day we receive data access. Projects that need an API pipeline or a staging database first take longer, typically six weeks or more depending on the sources.

The first days go on reading your data, not drawing charts. We list every column we plan to use, flag gaps, and agree definitions with you in writing. The model follows, then a first page, which you review on a call. After that, pages arrive in small batches so feedback is cheap to act on. The last stretch is security testing with real managers and a recorded handover.

Delays in the Kingdom are rarely technical. Waiting for Microsoft 365 admin access, a Foodics or Salla API approval, or the accountant's sign-off on definitions can each add a week. We put those dependencies on day one so they move in parallel with the build.

Working with a Power BI developer in India from Saudi Arabia

India is two and a half hours ahead of Saudi Arabia, so a 9 am to 4 pm working day in Riyadh runs from 11:30 am to 6:30 pm in India. Most of your working day overlaps with ours, and questions sent on WhatsApp are answered every day of the week, on India time.

Reviews happen on Microsoft Teams, Google Meet or Zoom, with the report shared on screen. We work inside your tenant as guest or licensed users you create, so nothing sits on our laptops that you cannot see. Invoices come from India in USD and are paid by Wise, bank wire or PayPal. The agreement is your written quote plus our published terms; anything extra, such as a confidentiality agreement, is written into that quote.

Who owns the reports and data, and how is personal data protected?

You own everything: the Power BI files, workspaces, apps, any staging database and pipeline code. They live in your Microsoft tenant and cloud account from the first day, and we are users you can remove.

Sales and loyalty data often contains names and phone numbers. Most management dashboards do not need them, so we leave personal fields out of the model unless a report genuinely requires them, and restrict any page that does. The SDAIA data governance platform is the official home of the Personal Data Protection Law and its guidance; your own lawyer should confirm what your reports may contain and who may view them.

On the technical side, we keep access to workspaces limited, use row-level security for branch data, avoid exporting raw data to email, and document which fields are held and why. We do not give legal advice or claim that a report is compliant; we build what your counsel asks for and explain how it works. For website-side privacy work, see our PDPL website compliance page.

AI on top of Power BI: Q&A, assistants and what to expect

Power BI's built-in Q&A lets people type questions about the model, but Microsoft lists it as English-only. For Arabic questions, or answers that combine dashboard figures with policies and documents, a separate assistant is the practical route.

We build that assistant on top of your model or staging database, so it quotes the same measures as the reports. A branch manager can ask “which items fell most this week in my branch” and get a short answer with the figure, limited by the same branch rules. AI assistants start from US$600 and are best added after the dashboards are trusted, because an assistant repeating a wrong number is worse than a chart showing one.

Clean, well-named measures also help when you later use Microsoft's own AI features, since those read the same model metadata. Short descriptions on every measure are part of our handover for that reason.

Red flags when hiring a Power BI developer remotely

The loudest warning is a developer who builds in their own tenant and offers to “share” the result. You would not own the model, the refresh or the history, and moving it later is avoidable work.

• Dashboards shown before anyone has looked at your data.
• No reconciliation against your accountant's figures for a closed month.
• Calculated columns everywhere instead of measures, making the model slow.
• Branch security promised, but managers set as workspace Members.
• Refresh owned by a personal account outside your company.
• Hijri comparisons done by eye rather than in the date table.
• A price quoted before the number of sources is known.

Worked example: a Power BI developer for a Saudi café chain

This scenario is hypothetical. Say a specialty coffee chain has nine branches in Riyadh and three in Al Khobar, uses Foodics at the tills, sells beans online through Salla, and keeps its books in Qoyod. The owner wants one morning view; area managers want their branches only.

In week one we would review sample exports, map products across Foodics and Salla, and agree that operations pages show VAT-inclusive sales while finance pages show net revenue. The calendar would carry Hijri months and Ramadan flags, because evening trade during Ramadan changes the whole hourly pattern. Security would use a mapping table with two regions and twelve branch managers.

Pages would cover an owner summary, hourly sales by branch, item mix, online versus in-store, and a monthly finance view from Qoyod. Refresh would run after closing and again mid-morning. The owner, the finance lead and two area managers would each need a Pro licence, bought by the chain; branch managers would view through a Power BI app, which on shared capacity also means a paid licence each, so the licence mix would be compared against capacity before rollout. The build would start from US$600, with an API pipeline from US$900 only if exports proved too manual.