Skip to content

Laravel in United Arab Emirates

Laravel development services for UAE companies

The backend half of building for the Emirates - an e-invoicing model with an accredited provider in the middle, and a working week that breaks scheduled jobs written elsewhere.

Building for the Emirates is often described as a localisation problem, which covers the visible half. The half that reaches the database is a tax model with an intermediary in it and a calendar that does not match the assumptions baked into most business software.

E-invoicing puts a third party in the middle

The UAE model is not "generate a file and submit it". Documents pass through an accredited service provider, which validates them, exchanges them with the recipient's provider and reports to the authority. Your application talks to that provider.

That has consequences worth designing for rather than discovering.

An invoice becomes asynchronous. It is created, sent, accepted or rejected - and the rejection can arrive after your user has been told the invoice went out. So an invoice needs a state machine, a queue, and a screen where somebody can see what is stuck, rather than a sent_at column.

The provider is a dependency you may change. Building their API shape directly into your invoicing code makes switching a rewrite. An interface with one implementation costs almost nothing now and is the difference between a migration and a project later.

And the document, not the PDF, is the invoice. The structured form is what counts legally, which means validation happens before anything is rendered and the archive stores the structured document alongside whatever a human reads.

The working week is not Monday to Friday

The UAE moved to a Saturday-Sunday weekend, with Friday a half day for the public sector. Every piece of software written for a Monday-Friday assumption is quietly wrong here, and the wrongness is invisible until it costs something.

Concretely: payment terms calculated in working days, SLA timers that should pause outside business hours, reports scheduled for "end of week", jobs set to run when nobody is working, reminder emails arriving on a day off.

// wrong here, and wrong silently
$due = now()->addWeekdays(5);

Carbon's default weekend is Saturday and Sunday, which happens to be correct for the UAE and incorrect for Saudi Arabia's neighbours in other ways - so the safe approach is neither the default nor a constant, but a working-week definition that belongs to the tenant or the country, configured rather than assumed.

Public holidays compound it. Several are set by moon observation and confirmed only a few days ahead, so a holiday calendar cannot be a file compiled at release time. It needs to be data somebody can update without a deploy.

Arabic reaches further than the templates

Right-to-left layout is a frontend concern and a well-understood one. What lands on the backend is text handling.

Sorting is a collation decision, made when the column is created. Searching is worse: Arabic has letters with multiple written forms, optional diacritics and two different characters that both look like a final ya. A customer searching for a name they typed differently from the way it was stored finds nothing, and nobody reports it as a bug because it looks like the record does not exist.

The fix is normalisation at write time, an index on the normalised form, and the original preserved for display. All three are cheap at design time and a backfill afterwards.

VAT, which is the simple part

Five per cent, with zero-rated and exempt categories that are not the same thing - a distinction that matters for reporting rather than for the total. As with any tax, the rate belongs to the line item at the time of issue rather than to a configuration value read at report time, because rates change and history should not.

Working with us from the UAE

We work remotely from Ankara, an hour behind Dubai - close enough that a question asked in the morning is answered in the morning.

The work itself is the application development, queue and database engineering we do anywhere. What the UAE adds is that the invoicing path is asynchronous by nature, the calendar is configuration rather than a constant, and the text handling has to be decided before the first migration runs.

Arabic reaching the database also reaches the front end, and the choice there is a real one. Blade, Livewire and Inertia each mirror differently once the layout is written in logical properties. Deciding before there is a component library to convert is much cheaper.

Invoicing and payment. In US dollars, by bank transfer to an IBAN. The invoice comes from Codefacture Yazılım A.Ş. in Türkiye, without Turkish VAT, because exported services are exempt. It arrives as a PDF and not through an accredited service provider, since that requirement sits on invoices issued inside the UAE.

Frequently asked questions

Do we send invoices to the tax authority directly?
No, and this is the structural difference from most systems teams have built before. The UAE model routes documents through an accredited service provider, so your application integrates with that provider rather than with the authority. Which provider you choose is therefore an architectural decision, not a procurement detail.
Does the data have to stay in the UAE?
Not as a blanket rule, and the answer depends on your sector and on which authority you answer to - mainland and the financial free zones have different regimes, and health and financial data carry their own requirements. It is a question with a definite answer for your situation, and it should be answered before a hosting region is chosen.
We already support Arabic on the frontend. Is that enough?
For display, often. For a backend, no: sorting, searching and matching Arabic text depend on the database collation, and a name typed with different forms of the same letter will not match unless the storage layer is set up to normalise it. That is a migration, and it is far cheaper before there are rows.
Is the Hijri calendar something we have to handle?
Usually for display rather than for storage, and the rule is the same as for any calendar - store the instant, convert at the edges. Where it does reach the logic is in holiday calculations, because several public holidays are set by observation and are announced only days in advance.
Call us+1 848 272 7583WhatsApp+90 850 308 5436Emailinfo@codefacture.comContact page