We are restoring the requested view from its saved state. Your account and work remain unchanged while you wait.
Back to the track — Value Added Tax Specialist
At day end the ledger shows 214 invoices and point of sale shows 214, but integration has 209 successful, three pending and two rejected. A clerk recreated the two failures under new numbers, and the designer placed a static QR in the receipt template. You must separate document from attempt, block non-final copies and reconcile count, amount and status.
Creating an invoice in Word, saving it as PDF and emailing it produces an electronic file, not an operational e-invoice. An e-invoice originates in a system that preserves fields, structure, identifiers, sequence and status; prevents silent alteration after issue; and links corrections to later documents. The human-readable image matters, but it is a rendering of data rather than the only source of truth. The accountant therefore checks more than whether a document looks official: is the type correct, are fields complete, do amounts reperform, is the identifier unique, does status evidence what happened, and does the readable copy agree with retained structured data?
Type is the first decision. Tax invoices are used mostly B2B and simplified invoices mostly B2C, but the rule is not reducible to those labels. A taxpayer may choose a simplified invoice for B2B when taxable supply value is below SAR 1,000, while that threshold does not limit B2C transactions. The issue screen checks customer type and registration, transaction nature and taxable supply value; a missing tax number does not itself convert the document. Then apply the current field matrix by type and phase rather than a memorised count, because the integration data dictionary is broader than a Phase 1 list.
The generation phase began on 04/12/2021 and moved invoices and notes away from editable manual tools. Integration began in waves on 01/01/2023, with targeted groups notified in advance. Those dates alone do not establish that a particular business belongs to a current wave; applicability must be confirmed separately by the authorised owner using a current official source. The accountant needs the evidence consequence: generation requires an invoice from a controlled solution, while integration makes submission or clearance messages and responses part of the document file. A successful print is not enough.
| Document | Operational integration route | Evidence retained |
|---|---|---|
| Tax invoice | Clearance before treating it as issued in the applicable route |
The treatment starts from these documents. Follow the numbers to identify recognition date, amount, counterparty, reference and approval evidence before preparing the entry.
Facts and supporting evidence
A cleared tax invoice: net 100,000.00, VAT 15,000.00 and gross 115,000.00.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Accounts receivable | 115,000.00 | |
| Sales revenue | 100,000.00 | |
| Output VAT | 15,000.00 | |
| Total (SAR) | 115,000.00 | 115,000.00 |
Treatment and financial effect
Identifier, status and readable copy link to the same entry; a pending copy is not delivered as final.
Reperformance starts from this case's own facts: A cleared tax invoice: net 100,000.00, VAT 15,000.00 and gross 115,000.00. Obtain the original source that proves this event. The training drawings Tax invoice status record, Simplified invoice control sheet explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the tax invoice, supply evidence, tax point and counterparty status, then confirm that the source supports the debit side (Accounts receivable) and the credit side (Sales revenue, Output VAT). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 115,000.00 and total credits 115,000.00. Debit detail: Accounts receivable for 115,000.00. Credit detail: Sales revenue for 100,000.00; Output VAT for 15,000.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the output and input VAT ledgers and return bridge. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: Revenue is overstated and tax liability understated by 15,000.00 despite invoice success. Do not close until the journal agrees with return boxes, general ledger and ZATCA evidence pack and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
The ERP links sales order, invoice, journal and integration register. Generation, submission, clearance or reporting status must be searchable by identifier, and the system blocks final output from a non-successful state under the applicable route. Retry permission should not automatically create a new document; pending and rejected rows are monitored by age and amount.
Complete a file for four documents: tax invoice, simplified invoice, credit note and rejected attempt. Link type to customer, fields to arithmetic, status to identifier and journal to register.
Work output: A workbook
These are yours once downloaded, and need no account. Fill them with your own figures and keep them in your portfolio.
Check fields and arithmetic on a tax invoice, remembering the tool does not prove customer type or integration status.
An invoice moves from draft to final status while a rejected attempt appears that must not become a second sale.
What you haveThe customer is VAT-registered, taxable supply is 100,000.00 and master data is complete.
The arithmetic in this case runs in the tool itself, which is open to you any time with your own figures.
Write which link broke: type to customer, fields to data, status to identifier, or correction to original. Record count, amount and owner before retry.
This is not sent anywhere and not stored here. Write it down for yourself — in the workpaper you downloaded, or on paper.
An e-invoice is data, identifier, status and readable copy. Type follows transaction, customer and B2B threshold; correction uses a linked document, and rejection stays inside the chain.
Ledger and sales register agree, but two invoices are rejected and three pending. Is close sound, and which reconciliations are missing?
Answer every question. Getting them all right records this lesson; you may retry as often as you need.
Reading alone records nothing.
The complete applied walkthrough is available below while the recording is prepared.
I slide aside a complete-looking PDF to reveal structured data, identifier, status and readable copy. Before routing I place B2C, B2B and SAR 1,000 cards to show type is not chosen from one field. Then a rejected and successful attempt share one identifier, while a new number creates a duplicate sale. An attempt is not a sale and an image is not a lifecycle.
| Data, response and readable copy |
| Simplified invoice | Report within 24 hours of issue | Data, reporting status and QR |
|---|
| Credit or debit note | Follows the original document type and links to it | Original identifier, correction reason and status |
|---|
Under clearance, pressing Issue does not mean an invoice has reached the state in which the applicable process allows it to be delivered to the customer. A successful response must link to the identifier, and a rejected or pending copy must not be used as final. Under reporting, submission cannot become an ownerless overnight job; pending, late and rejected rows are monitored and resubmitted under a defined procedure. Technical failure does not justify a manual invoice outside the chain, because that solves an immediate problem by creating a document missing from the status register. Good continuity preserves identifiers and sequence and resynchronises without duplication.
A QR code is not a visual seal proving everything is correct. Its presence forms part of document requirements in context, but a QR image can sit over missing data, a wrong amount or the wrong invoice type. Review starts with fields, arithmetic, type and status, then confirms the code belongs to that document and is not a reused static image. A weak implementation may place one QR in every template, making pages look modern while failing the core truth: identifier and data do not change with each transaction. Test the code from a real sample against system data rather than accepting its appearance in the corner.
When an invoice is rejected, the system records reason, time, identifier and submitted version. The user corrects the cause and retries in a way that preserves the chain. They do not copy the document into a new number on every attempt or alter a successful document without a later note. Repeated retries can create multiple invoices for one sale or a gap between ledger and submission register. The monitoring view therefore distinguishes attempt, message and final accounting document. The accountant reconciles populations: what sales created, what reached integration, what succeeded, what failed and what entered the ledger. Every group has a count, amount and owner for differences.
After issue, correction uses a credit or debit note linked to the original rather than deletion or overwriting. The link carries original reference, reason, net, VAT and customer consequence, and a required note is issued within 15 days following the end of the month in which its triggering event occurred. A descriptive change with no amount effect follows the documentary-correction process rather than an invented financial movement. Retain original, note, each status, event date, deadline and actual issue date.
Retention is not a PDF folder. The invoice record needs source data, readable copy, status messages, linked notes, change log and recoverable backups. Standard VAT retention is six years, extended to 11 years for invoices and records connected with movable capital assets and 15 years for immovable capital assets. The schedule therefore records type, retention start and permitted disposal date instead of applying six years to everything. Search must work by identifier, customer, date and amount, and restoration must be tested.
At close, three reconciliations are performed. Numerical: sales register to ledger for net, VAT and gross. Operational: generation register to integration statuses for counts and amounts successful, pending and rejected. Documentary: a sample checks correct type, fields, QR, unique identifier and agreement between readable and structured data. Passing the first does not cover failure of the second; an accounting entry can be right while its invoice has not reached the required state. Passing the second does not cover the third; consistent data may use a wrong customer type. Separating tests lets each say something precise instead of issuing a vague system-works stamp.
Control is completed by separating permissions. A person who creates a customer or changes tax status should not approve the same exception invoice without review, and a person retrying a failed message should not be able to delete the rejection log or alter the original identifier. Credit-note permission should not allow an unreferenced, unexplained note merely because its holder works in sales. Role reports alone are insufficient; review actual actions: customer-status changes near issue, repeated attempts by one user, invoices succeeding after manual edits, and notes without originals. Linking user, time and identifier makes errors explainable and prevents an urgent workaround becoming a permanent route around the document lifecycle.
Facts and supporting evidence
A simplified cash invoice for 1,150.00 inclusive; net 1,000.00, VAT 150.00, reporting successful.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Cash | 1,150.00 | |
| Point-of-sale revenue | 1,000.00 | |
| Output VAT | 150.00 | |
| Total (SAR) | 1,150.00 | 1,150.00 |
Treatment and financial effect
Receipt data, QR, reporting status, point-of-sale register and ledger agree to one transaction.
Reperformance starts from this case's own facts: A simplified cash invoice for 1,150.00 inclusive; net 1,000.00, VAT 150.00, reporting successful. Obtain the original source that proves this event. The training drawings Tax invoice status record, Simplified invoice control sheet explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the tax invoice, supply evidence, tax point and counterparty status, then confirm that the source supports the debit side (Cash) and the credit side (Point-of-sale revenue, Output VAT). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 1,150.00 and total credits 1,150.00. Debit detail: Cash for 1,150.00. Credit detail: Point-of-sale revenue for 1,000.00; Output VAT for 150.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the output and input VAT ledgers and return bridge. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: The customer copy cannot be linked to its data, breaking verifiability and retention despite correct VAT of 150.00. Do not close until the journal agrees with return boxes, general ledger and ZATCA evidence pack and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
Facts and supporting evidence
An electronic credit note for a return of net 5,000.00 and VAT 750.00, linked to the original invoice.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Sales returns | 5,000.00 | |
| Output VAT | 750.00 | |
| Accounts receivable | 5,750.00 | |
| Total (SAR) | 5,750.00 | 5,750.00 |
Treatment and financial effect
The note carries original identifier, correction reason and status, preserving both versions rather than overwriting the invoice.
Reperformance starts from this case's own facts: An electronic credit note for a return of net 5,000.00 and VAT 750.00, linked to the original invoice. Obtain the original source that proves this event. The training drawings Tax invoice status record, Simplified invoice control sheet explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the tax invoice, supply evidence, tax point and counterparty status, then confirm that the source supports the debit side (Sales returns, Output VAT) and the credit side (Accounts receivable). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 5,750.00 and total credits 5,750.00. Debit detail: Sales returns for 5,000.00; Output VAT for 750.00. Credit detail: Accounts receivable for 5,750.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the output and input VAT ledgers and return bridge. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: Returns are overstated by 750.00, VAT did not fall, and the electronic trail is missing. Do not close until the journal agrees with return boxes, general ledger and ZATCA evidence pack and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
Facts and supporting evidence
A retry created a duplicate with net 20,000.00, VAT 3,000.00 and receivable 23,000.00.
Correct treatment and entry
| Account | Debit | Credit |
|---|---|---|
| Sales revenue | 20,000.00 | |
| Output VAT | 3,000.00 | |
| Accounts receivable | 23,000.00 | |
| Total (SAR) | 23,000.00 | 23,000.00 |
Treatment and financial effect
Once the second document is proven duplicate, reverse its full effect and retain both attempt records and the reason.
Reperformance starts from this case's own facts: A retry created a duplicate with net 20,000.00, VAT 3,000.00 and receivable 23,000.00. Obtain the original source that proves this event. The training drawings Tax invoice status record, Simplified invoice control sheet explain field shape and reading order; they do not replace the case document or transfer their figures into it. Match entity, period, currency, reference and version to the tax invoice, supply evidence, tax point and counterparty status, then confirm that the source supports the debit side (Sales revenue, Output VAT) and the credit side (Accounts receivable). Missing ownership, date, reference or approval remains an open exception; a balancing journal or undocumented assumption does not cure it.
Remeasure from the facts before reading the proposed journal, then add it independently: total debits 23,000.00 and total credits 23,000.00. Debit detail: Sales revenue for 20,000.00; Output VAT for 3,000.00. Credit detail: Accounts receivable for 23,000.00. Link every line to the recognition or measurement rule explained in the lecture, then trace its reference and posting date. After posting, test the output and input VAT ledgers and return bridge. Equal sides prove arithmetic only, not the correct account, period or classification.
Before close, compare the correct treatment with the common alternative and record its specific effect: Revenue, VAT and customer are duplicated by 20,000.00, 3,000.00 and 23,000.00. Do not close until the journal agrees with return boxes, general ledger and ZATCA evidence pack and an independent reviewer can move from balance to account, reference and this event's own source. Keep the calculation, source version, journal identifier, reconciliation result and unresolved exceptions in the same workpaper. An attached file without a stated conclusion is not review evidence.
The invoice is complete; its input tax is deductible