Submission Recovery

Submission Recovery

Overview

Networks drop, ZATCA servers experience downtime, and high-volume trading periods can introduce submission delays. The question is not whether submission failures will occur, but how quickly and completely your system recovers from them.



Info
iVendNext approaches ZATCA submission resilience as a core operational requirement. The system includes a background scheduler that continuously monitors and retries failed submissions, dedicated handling for ZATCA platform downtime, bulk recovery tools for large-scale outages, and a comprehensive logging layer that gives IT and finance teams full visibility into every submission outcome. This article explains each of these capabilities and what your team should know about monitoring compliance health and responding to failures.



The ZATCA Compliance Dashboard

The primary monitoring tool is the ZATCA Compliance Dashboard — a dedicated page in iVendNext Desk presenting a real-time summary of invoice submission states across all companies. The dashboard shows submission counts broken down by status: Reported, Cleared, Not Submitted, and Error.


Notes

For multi-entity or multi-branch operations, the dashboard aggregates data across all configured companies, allowing a compliance officer or IT administrator to monitor the entire estate from a single screen. If submission errors are accumulating in a particular company — for example, due to a network issue at a specific branch — this becomes visible in the dashboard counts before it becomes a regulatory problem.




Submission Status Badges on Invoice Records

Every invoice form in iVendNext displays a ZATCA submission status badge directly on the record: Reported, Cleared, Pending, or Failed. Any team member with access to an invoice — an accounts manager investigating a transaction or a customer service rep handling a dispute — can immediately see its ZATCA compliance state without navigating to a separate report.


Info

The badge updates in real time as the submission state changes. An invoice initially showing Pending will update to Reported or Cleared once the ZATCA response is received, and will update to Failed if the submission is rejected or times out.



Background Scheduler and Auto-Retry

The core of iVendNext's submission resilience is a background scheduler that runs every ten minutes and automatically processes invoices that have not yet been successfully submitted. The scheduler targets failed invoices from the previous 24 hours — the window within which ZATCA requires B2C invoices to be reported.



Notes
The scheduler operates without IT intervention. When a submission fails, the invoice is flagged for retry and the scheduler will attempt resubmission on its next cycle. Temporary failures — a momentary network drop, a brief API timeout — self-heal within minutes without manual action. The 24-hour retry window aligns with ZATCA's reporting deadline for B2C invoices.




Bulk Resubmission from List View

For situations where a larger number of invoices have failed — after an extended network outage affecting an entire branch — iVendNext provides a bulk resubmission tool accessible from the invoice list view. Administrators or accounts managers can filter by submission status (Failed or Not Submitted), select multiple records, and trigger resubmission to ZATCA in a single action.


Info

This eliminates the need to open each invoice individually, which would be impractical at scale. Only users with the Accounts Manager role or above can trigger bulk resubmissions — POS Users have no access to this function.



Full ZATCA Response Logging

Every interaction with the ZATCA API is logged in full on the corresponding invoice record — including the complete API response body, clearance XML for cleared invoices, warning codes, and error descriptions for failed submissions.



Notes
For day-to-day operations, this allows IT administrators to diagnose failures quickly by searching for a specific invoice and reading the exact error returned by ZATCA. Common error patterns — VAT number mismatches, certificate expiry, address validation failures — are identifiable directly from the log without needing to reproduce the issue.


For regulatory purposes, the full response log provides a complete audit trail of every submission attempt and outcome, constituting evidence not just that an invoice was submitted, but exactly what ZATCA returned in response and when.



ZATCA Success Log

iVendNext also maintains a ZATCA Success Log — a dedicated record per successful submission capturing the invoice number, UUID, submission timestamp, and API response. This is an iVendNext feature that exists separately from the invoice record, providing a clean, searchable evidence trail useful for compliance reporting, deadline verification, and producing submission records during an audit.



Role-Based Access Controls

iVendNext controls access to ZATCA functions by role. System Managers have full access to ZATCA settings and configuration. Accounts Managers can resubmit failed invoices individually or in bulk but cannot modify configuration. POS Users — the cashiers generating invoices — have no access to ZATCA settings or submission controls. This role structure is an iVendNext design choice, separating compliance configuration from day-to-day recovery tasks so accounts teams can handle resubmissions without IT involvement.



Multimode Transaction Validation

iVendNext includes a pre-submission validation layer that detects invoices containing incompatible transaction types before any API call is made. ZATCA's specification prohibits certain transaction type combinations within a single document, and submitting such an invoice would result in a rejection. By catching these conflicts at the iVendNext level, the system prevents the submission queue from being polluted with invoices that will never succeed and surfaces a clear error for the accounts team to resolve.



Summary

iVendNext's submission resilience layer ensures no invoice is permanently missed due to a technical failure. The background scheduler handles routine retries automatically. Downtime scenarios are managed with ZATCA-specific holding logic. Bulk resubmission tools make large-scale recovery practical. Comprehensive logging at both invoice and success-log level ensures every outcome is recorded and auditable. Together, these capabilities allow your retail operation to maintain continuous ZATCA compliance through network outages, platform downtime, and high-volume trading conditions — without placing undue burden on store staff, finance teams, or IT.




    • Related Articles

    • Managing Sales Orders After Submission

      Overview This article provides a step-by-step guide to managing Sales Orders after they have been submitted, ensuring smooth order fulfillment and customer satisfaction. Note: You can update Rate and Qty in a Submitted Sales Order, by clicking on the ...
    • Post-Submission Actions: Purchase Receipts, Invoices, and Payments

      Overview This article outlines the key post-submission actions in iVendNext, including how to create Purchase Receipts, generate Purchase Invoices, and manage Payment Entries. 1. Understanding Post-Submission Actions 1.1 Purchase Receipts A Purchase ...
    • Editing Fields After Submission and Changing Data Types

      Overview Efficient data entry and clear document identification are critical for productivity in iVendNext. This guide covers two powerful features: Setting default values to automate repetitive inputs. Creating multi-field document titles for better ...
    • Working with Client Scripts for Enhanced UI

      Overview Client Scripts in iVendNext allow users to customize and extend the functionality of forms dynamically. These JavaScript-based snippets enable real-time modifications—such as hiding buttons, validating fields, or triggering actions—without ...
    • Invoice Compliance

      How iVendNext Handles KRA Invoice Submission For a retail business operating in Kenya, every POS Invoice is simultaneously a sales transaction and a tax event. Kenya Revenue Authority requires the transaction data to reach eTIMS before — or at the ...