A refrigerated container of dairy product lands at Jeddah Islamic Port. The supplier is approved, the product is listed, the invoice is clean. Three days later the Saudi Food and Drug Authority posts a clearance rejection against the customs declaration, and the importer's operations lead is looking at a re-export order, a destruction order, or a 60-day appeal — while cold storage bills accrue daily.
Nothing about the goods was wrong. The temperature logger reading, the shelf-life remaining on arrival, and the product listing record disagreed with each other. That is a data reconciliation failure, and it is the single most common shape of an SFDA rejection.
Two systems, both called "clearance"
The vocabulary trips up almost every team new to Saudi importing, and the confusion costs real days.
Fasah (fasah.sa) is the national single window for import and export, operated by Tabadul under the Zakat, Tax and Customs Authority. It is where the customs declaration lives, where the clearance agent is authorised, and where the shipment status is tracked across every participating government body.
Faseh (faseh.sfda.gov.sa) is the SFDA's own electronic clearance system, covering food, pharmaceuticals, medical devices and cosmetics. It is where the regulator decides whether a specific consignment of a regulated product may enter the market.
Fasah routes the shipment. SFDA decides its fate. Saber, which we covered in our piece on Saber certificate rejections, is a third system entirely — it handles SASO conformity for consumer products and is now linked into the clearance flow, which means a defect in one system surfaces as a hold in another. Teams routinely spend a day chasing the wrong portal because the rejection notice appeared on Fasah while the actual decision was made in Faseh.
The rejection reasons are not random
In October 2025 the SFDA published its documented grounds for refusing consignment clearance. Read as a list they look bureaucratic. Read as data, they sort into four clean categories.
Food. Import from a non-approved facility; packaged food labelling non-compliance; food additive regulation breaches; trans-fat requirements; transport and storage conditions; failed laboratory analysis.
Pharmaceuticals. No temperature indicator shipped with the consignment; temperature excursion during transport; failed analysis; missing certificate of analysis.
Medical devices. No declaration of conformity attached; expired marketing authorisation; no designated authorised representative; no prior import permit obtained.
Cosmetics. Product not listed; product failed approved testing; medical claims on packaging; delivered product does not match what was listed; contains pharmaceutical or prohibited substances; analysis fees unpaid.
Look at what actually triggers these. An expired marketing authorisation is a date field. A missing authorised representative is a relationship record. A delivered product that does not match the listing is a SKU mismatch between the supplier's packing list and the SFDA listing database. A temperature excursion is a time series that nobody read before the container was unloaded.
The SFDA itself has said as much publicly: incomplete documentation and unmet clearance requirements are the leading causes of delay, not unsafe goods. That is an important distinction, because it means the problem is fixable upstream at almost no cost — and expensive to fix downstream at the port.
Nobody checks the documents against each other
Here is the process as it actually runs in most importers we see.
Procurement holds the purchase order in the ERP. The supplier emails a packing list and a certificate of analysis as PDFs. The freight forwarder holds the bill of lading. The regulatory affairs person holds the SFDA listing numbers in a spreadsheet that was last fully reviewed when the product range was smaller. The cold-chain logger data arrives as a proprietary file that gets opened once, at the port, after the shipment is already there.
Each document is individually correct. No system compares them. The first entity that ever performs the cross-check is the regulator, at the worst possible moment, with the most expensive possible consequence.
The checks that would have caught the rejection are trivial in code and were simply never assigned to anyone:
- Does every SKU on the packing list exist in the SFDA listing, with a listing that has not expired before the estimated arrival date?
- Does the remaining shelf life on arrival clear the minimum percentage required for that product category?
- Does the marketing authorisation for each medical device expire after the expected clearance date, not merely after the shipping date?
- Is the authorised representative on file the same legal entity named on the declaration of conformity?
- Did the temperature logger stay in range for the whole voyage, and is that file attached in a readable format?
- Do the product names on the label, the invoice, the certificate of analysis and the listing record match, in both Arabic and English?
That last one causes more trouble than any other single item. Arabic label text transliterated one way in the listing and another way on the invoice reads to a reviewer as two different products.
The 60-day clock is a retrieval problem
If a consignment is rejected, the importer may object. The window is 60 days from the date of the clearance decision. The objection form must be certified by the Chamber of Commerce and submitted through the SFDA's request channel, accompanied by the complete shipment documentation and a direct response to each stated reason for rejection. Only one objection may be filed per customs declaration — there is no second attempt if the first is assembled badly.
Sixty days sounds generous. It is not, because the clock runs against storage charges that continue the whole time, and because the burden of assembling a complete evidentiary file falls on an organisation whose documents are scattered across email, a shared drive, a forwarder's portal and an ERP. The teams that win appeals are the ones that can produce every document tied to a consignment in an afternoon. The teams that lose are the ones still asking the supplier to resend a certificate in week six.
Note that "one objection per declaration" makes the quality of the first submission decisive. An appeal file that answers four of five rejection reasons is a lost appeal.
Why "just use the API" is not the answer
The reasonable engineering instinct is to integrate directly: pull consignment status from Faseh, push documents, validate against the listing database programmatically. That path is largely closed. There is no general-purpose public developer API for bulk consignment clearance, and access to the government integration layer runs through licensed participants in the single-window ecosystem rather than through a developer signup page. The community-built connectors that exist, such as the Odoo SFDA integration module, are a symptom of the demand rather than a real platform.
This constraint is the same one we hit with Saber, and it points to the same conclusion: the leverage is not inside the government platform, it is in front of it. You cannot make the regulator's system easier to talk to. You can make sure that by the time you talk to it, you have nothing left to be rejected for.
A pre-arrival reconciliation layer
What this looks like in practice is unglamorous and effective — a service that sits between your existing systems and the port.
One consignment record. A single object that ties the purchase order, supplier documents, SKU list, listing references, logger file and bill of lading together, keyed by customs declaration number. Everything else depends on this existing.
A rules engine over the documented rejection reasons. Each published ground for refusal becomes an assertion that runs against the consignment record. Date comparisons, set membership, numeric thresholds, string matching across languages. This is ordinary validation code, not machine learning.
Time-aware checks. Validate against the estimated arrival date, not today. A listing that is valid when the container is loaded and expires mid-voyage is the classic avoidable rejection.
Cold-chain ingestion at departure. Parse the logger export when the shipment leaves, not when it arrives. An excursion detected at origin is a commercial conversation with a supplier; the same excursion detected at Jeddah is a destruction order.
A dossier generator. When a rejection does happen, one command produces the complete appeal pack — every document, indexed against each stated reason, ready for Chamber of Commerce certification.
None of this requires the regulator's cooperation. All of it runs on data you already hold, and it is the same architectural pattern that works for WPS payroll reconciliation and NPHIES claim denials: the government platform is a validator with expensive failure modes, so you build a cheaper validator and run it first.
What to check before the next shipment
Three questions, answerable this week without writing any code:
- Can you list, right now, every SKU currently in transit and the expiry date of its SFDA listing? If that takes more than an hour, you do not have a consignment record, and every clearance is a coin flip.
- When was the last time someone opened a temperature logger file before the container arrived? If the answer is never, your cold-chain compliance is discovered rather than managed.
- Pull your last five rejections and sort them by cause. If three or more trace back to a document disagreeing with another document, the fix is a reconciliation layer, not a better clearance agent.
The pattern that keeps repeating across Saudi government platforms — Fasah, ZATCA e-invoicing, Qiwa, NPHIES — is that the regulator has digitised the checking, while most companies have not digitised the preparing. The gap between those two is where the penalties, the demurrage and the destruction orders live.
If you are carrying rejections you cannot explain, we will read your last quarter of clearance decisions with you and tell you which ones were data problems and which ones were genuinely goods problems. That diagnosis is usually enough to size the fix — get in touch and bring the rejection notices.