Custom WordPress website development
in Abu Dhabi

A WordPress site that sells through WooCommerce in Abu Dhabi has to treat VAT as part of the build. Not something bolted on after launch. Any business registered for VAT must issue a proper tax invoice for every sale. That invoice carries specific information: the Tax Registration Number of the seller, the amount of VAT charged, a description of what was sold, the date, and enough buyer detail for later checks. A default order confirmation contains almost none of that.

The Tax Registration Number belongs on every tax invoice a VAT-registered seller sends out. It needs its own field in the template. Not a line typed into a notes box. The same goes for the VAT amount. Show it on its own line, separate from the price and the total. A reviewer can then see what was charged, and why. One combined figure looks tidy. It fails the moment someone asks.

For most goods, the price shown already includes VAT. The number on the product page should match the checkout number. No exceptions. A store that quotes one figure on the shelf should not add a surprise line at the end. That kills trust fast. Price display settings in WooCommerce decide whether tax sits inside the listed price or gets added afterward. That setting is not decoration for a shop selling to consumers.

Not every product carries VAT the same way. Some items may be zero-rated or exempt under the rules that apply in the UAE. The store needs a tax class built at the product level. A single blanket setting will not do it. Skipping this step means every invoice states the same treatment. That mismatch is exactly what a later review would catch. Check new products first.

WooCommerce on its own generates an order confirmation, not a compliant tax invoice. Most VAT-registered stores add a plugin that produces a numbered, sequential PDF for every order. Sequential numbering matters here. Gaps in a run of numbers are the first thing a review looks for. Configure the plugin before launch. Not after hundreds of orders have gone out under a plain template. The PDF should carry the same seller, buyer, and VAT details as the rest of the record.

A refund is not a deleted invoice. When an order is cancelled or an item returned, the correct document is a credit note. It references the original invoice number and states the VAT being reversed. The adjustment stays traceable. A refund workflow that only changes the order total, without generating a matching credit note, leaves a gap. Test this with a refunded order, not a cancelled one that never charged VAT.

Records also have to stay available for review by the UAE tax authority: the invoices, the credit notes, and the order data behind them. Relying on the database alone carries risk. A migration, a plugin conflict, or a careless cleanup can remove years of history. Regular exports to a format that survives outside the website turn a legal obligation into routine housekeeping.

None of this changes how the store looks to a shopper. It changes what happens behind every button. Treat VAT as a specification item from the first meeting. That avoids retrofitting invoice fields onto orders that have already gone out.

WordPress ships with a handful of roles: Administrator, Editor, Author, Contributor, Subscriber. Most teams default to giving everyone Administrator, because it is the fastest way to stop support requests. It is also the fastest way to create a problem. A real one. Every extra administrator account is another way into plugin settings, the theme editor, and the list of every other user on the site.

An Author can publish their own posts but cannot touch anyone else. That works fine until a colleague goes on leave mid-week and nobody else can edit or schedule what they left behind. An Editor can see and change everything written by the whole team, which solves that gap, but it also means an Editor can quietly rewrite a post nobody asked them to touch. Neither role is wrong. The mismatch shows up only once the team is watched for a few weeks.

A Contributor can draft a post but cannot publish it. Every draft waits. Someone else has to review and push it live. That friction is a feature for a freelance writer or a guest contributor, and a genuine irritation for a founder who wants to post an update the same afternoon they wrote it. Assigning Contributor to the wrong person turns a simple workflow into a bottleneck nobody remembers approving.

The default five roles map to a fairly flat structure. Plenty of real teams are not flat. A site with a marketing lead, two writers, and a developer who only touches templates does not fit neatly into Administrator, Editor, Author. A capability plugin can build a role that edits posts and manages media but never sees the plugin list or the theme files. That matches access to the actual job, not the closest default label.

Scheduled and pending statuses matter as much as the role itself. A post marked pending review sits visibly in a queue, rather than as a draft nobody remembers exists. A reviewer can then see what is waiting, without hunting through the post list. That is the point. Make it a team habit, not a setting left untouched, and drafts get reviewed before the deadline rather than after it.

When someone leaves, deactivate the account. Do not delete it. Deleting a user can strip their name from every post they wrote, or reassign the whole archive to whoever runs the deletion, neither of which anyone wanted. Changing the role to something with no login rights, while keeping the account attached to its posts, keeps the site history intact.

None of this shows up on the public side of the site. Not at all. It shows up the first time two people try to edit the same page at once. Or when a former freelancer still has a working login six months after the last invoice. That is exactly when a role that was never quite right finally becomes a problem worth fixing.