Most rejections trace back to a handful of recurring data problems — here's what they look like and how dsFatoora handles each one.
ERPs often store more (or fewer) decimal places than ZATCA's schema expects. A value that rounds cleanly in the ERP can fail validation once reformatted. Fix: dsFatoora normalizes precision at extraction, before any calculation happens downstream.
Line-by-line rounding vs. rounding the invoice total can produce a one-cent mismatch that ZATCA's business validation rejects — especially visible on invoices with many line items. Fix: a single, consistent rounding method applied across the whole invoice, matching ZATCA's expected calculation order.
Consolidated invoices with hundreds of SKUs can hit payload size limits or timeout on submission if sent naively. Fix: dsFatoora chunking and asynchronous submission handling keeps large invoices within API limits without losing line-item integrity.
A credit note referencing an original invoice that itself had warnings — or was submitted out of hash-chain order — can trigger confusing downstream rejections. Fix: dsFatoora tracks the full lineage of an invoice and its credit/debit notes, and enforces submission order.
Retried or out-of-order submissions can break the PIH chain if sequencing isn't enforced centrally. Fix: dsFatoora's middleware layer — not individual ERP connectors — owns the hash chain, so ordering is guaranteed regardless of which system submitted first.
Foreign-currency invoices need a consistent exchange rate source and rounding rule to avoid tax-total mismatches after conversion to SAR. Fix: a single configured rate source per client, applied identically at every conversion step.