diff --git a/assets/guides/sa-dashboard.png b/assets/guides/sa-dashboard.png
new file mode 100644
index 00000000..b4f97e4a
Binary files /dev/null and b/assets/guides/sa-dashboard.png differ
diff --git a/guides/sa-zatca-clearance-reporting.mdx b/guides/sa-zatca-clearance-reporting.mdx
index 51c47cf1..b51544c6 100644
--- a/guides/sa-zatca-clearance-reporting.mdx
+++ b/guides/sa-zatca-clearance-reporting.mdx
@@ -62,6 +62,20 @@ The send workflow claims the next ICV, builds and hashes the UBL document, signs
Issued invoices can't be cancelled or edited once cleared or reported. Corrections are made with **credit notes** (reduction) or **debit notes** (increase) that reference the original invoice. A note flows through the same clearance or reporting model as the document it corrects, using the same send workflow.
+## Reading the chain
+
+The ZATCA invoices dashboard lists every invoice the workspace has sent to ZATCA, newest first, so you can follow the cleared and reported chain at a glance.
+
+Each row surfaces the chain values ZATCA mandates: the **ICV** and the document **Hash** (each invoice's hash seeds the next invoice's PIH, linking the documents into a tamper-evident chain), alongside the **Silo Entry** that holds the document, the supplier **Tax Code**, the invoice **ID** and its **Previous ID**, and the **Created at** timestamp. In sandbox, an extra **Environment** column separates Simulation from Developer invoices.
+
+
+ 
+
+
+
+ Rows with an empty **Silo Entry** are the compliance sample invoices Invopop submits during [registration](/guides/sa-zatca-registration) to obtain the Production CSID. They advance the chain but are generated before any real document exists, so no silo entry backs them.
+
+
## Example invoices