A company where VAT treatment depends on which employee enters the transaction has a configuration problem that more training will not fix.

Saudi VAT has standard-rated, zero-rated, exempt and out-of-scope treatments, and assigning them transaction by transaction is not a job for individual judgment at volume. Correct configuration assigns the treatment by default from product and customer attributes. The user records what happened commercially and the system determines the tax consequence. This feeds directly into VAT return filing.

Tax codes and default assignment

The configuration defines a tax code for each treatment and assigns defaults at product group and customer level. An export, a domestic sale to a consumer, an exempt financial service and a purchase from an unregistered supplier each need to resolve automatically. Where a transaction calls for judgment, the system should force a deliberate choice instead of silently applying a default that may be wrong.

Input VAT and recovery

Purchases need equal attention: recoverable and non-recoverable input VAT, blocked items, reverse charge on imported services, and correct handling of purchases from unregistered suppliers. Businesses making both taxable and exempt supplies also need apportionment configured, which is where VAT positions most often stay quietly wrong for years.

Reporting from the ledger

The aim is a VAT return generated from the ledger instead of assembled in a spreadsheet. That requires tax codes that map cleanly to return boxes, adjustments and corrections that can be traced, and return figures that reconcile to the general ledger control accounts. Where this works, return preparation becomes a review task. Where it does not, every filing period carries error risk.

A hypothetical example

Consider a services company that zero-rates all of its exports by default. A configuration review would test whether that default holds for each customer type under the place-of-supply rules, and would change the tax codes so treatment resolves from customer attributes instead of a blanket assumption.

Validation and ongoing control

After configuration we run test transactions across the scenarios the business encounters and reconcile the resulting tax postings. Periodic review matters too, since a new product line, a new customer type or a change in rate or rule can each invalidate an assumption. A regular VAT health check tests whether the configuration still matches how the business trades.

Documenting the treatment decisions

Every non-obvious tax code assignment should carry a written rationale that cites the relevant provision, so a different person can later understand why a customer type is treated as it is. Undocumented decisions turn a defensible position into an indefensible one once the person who made them leaves. Our audit support relies on this documentation, and it also supports your registration and filing positions.