Cyprus VAT Return From Supplier Invoices & Credit Notes

To prepare a Cyprus VAT return from supplier invoices, you extract a purchase-register row for each invoice and credit note in the period, classify each row by VAT treatment, and roll the classified totals into the boxes on the current return in Tax For All. The return itself is the easy part once the worksheet is right. Getting the worksheet right is the work.

The fields the worksheet carries, per row, are: supplier name and VAT number, document number, issue date, tax-point date where separately stated, net value, VAT amount, VAT rate or category, reverse-charge flag, EU acquisition details, and the original-invoice reference for any credit note. That field set is what the rest of this guide builds on. Capture all of it on every row and the box totals fall out at the end; skip fields selectively and you end up reconstructing rows under a query later.

The current Cyprus VAT return uses boxes 1-11B. Boxes 1-5 carry VAT amounts: box 1 is output VAT, box 2 is the output side of EU-acquisition self-assessment, box 3 is total output VAT (boxes 1 plus 2), box 4 is input VAT, and box 5 is the net amount payable or refundable (box 3 minus box 4). Boxes 6-11 carry values excluding VAT, with boxes 11A and 11B covering EU acquisitions of goods and services respectively. Most of the purchase-side work lands in box 4 and box 7, with EU-acquisition rows also flowing through 11A or 11B.

This guide is written for the bookkeeper, in-house accountant, or finance owner sitting in front of a folder of received supplier documents at the start of a quarterly cycle. The shape of what follows is worksheet-first: the purchase-register schema, the invoice content the supplier document has to carry for the input VAT to be claimable, the classification taxonomy for the mixed input stream, the box mapping into the current return, the credit-note treatment, the practical step of producing the worksheet from PDFs at scale, and the reconciliation checks before the totals are entered in Tax For All. It is not a tax-law treatise, and it is not a tour of the Tax For All UI.

Four document classes show up as first-class inputs: supplier invoices, supplier credit notes, EU acquisition documents from VAT-registered suppliers in other EU member states (goods and services treated separately), and reverse-charge supplier bills (imported services and the domestic categories under Cyprus Article 11). Credit notes are treated as their own document type in the schema rather than netted into invoice rows; that distinction matters for the audit trail and is one of the two places this guide departs from the generic Cyprus VAT-return content currently ranking. The other place is the box structure: some guides still describe the Cyprus return as a 9-box process. The current return is 1-11B, and a worksheet built against the older layout will not align cleanly with what the portal accepts.

The Purchase-Register Schema: One Row Per Supplier Document

Put the schema into a fresh tab and treat the column set as a specification, not a draft. Every later step in this guide reads from these columns. The Cyprus purchase register for VAT return preparation lives or dies on whether the row grain is consistent and the columns carry enough metadata to defend any single row under a query.

Field	What it carries	Why it matters for the Cyprus return
Supplier name	Legal name as it appears on the document	Ties the row to the supplier statement at reconciliation
Supplier VAT number	Full number with ISO country prefix (CY, EL, DE, IE, etc.)	The prefix is what later separates Cyprus domestic input VAT from EU acquisitions and from non-VAT suppliers
Document type	Invoice, credit note, self-billed invoice, or reverse-charge bill	Drives both the sign of the row totals and which boxes they feed
Document number	Supplier's sequential invoice or credit-note number	Required content for a valid VAT document and the lookup key for any later query
Issue date	Date printed on the document	Anchors the row to a calendar period for sequencing and audit
Tax-point date	Supply or tax-point date where separately stated	Often equals the issue date; where it differs, the tax-point date drives the period the row belongs in
Net value	Document currency, excluding VAT	Source for box 7 and the related value-box totals
VAT amount	Document currency	Source for box 4 when the row is deductible
VAT rate or category	Standard, reduced, zero-rated, exempt, outside-scope, reverse-charge, EU acquisition	The classification column the next two sections populate
Currency and FX	Document currency, and the FX rate noted on the document where applicable	Foreign-currency rows need the EUR-converted net and VAT alongside the document-currency figures
Reverse-charge flag	Whether the supplier document carries reverse-charge wording, with the wording captured	The presence or absence of this wording on a reverse-charge bill is a content check, not a free-text note
EU acquisition flag	Goods or services, where the row is an EU acquisition	Separates boxes 11A and 11B treatment at the box-mapping step
Original-invoice reference	The underlying invoice number for any credit note	Mandatory for credit-note rows, blank for ordinary invoices; the binding field discussed at length later
Evidence reference	File name or stored-document ID linking back to the source PDF	The artefact a future query lands on; without it, the row is undefended

The columns are not independent. The document-type column carries credit notes into their own treatment in section 6 and changes how the totals sum. The VAT rate or category column is the one the classification step in the next section populates and is what the box-mapping crosswalk reads from. The EU acquisition flag drives whether a row hits 11A or 11B alongside its entry in the standard value boxes. The original-invoice reference is the load-bearing field for credit notes and is the only column where "blank" is meaningful information for non-credit rows. The evidence reference is what makes the worksheet defensible when a query arrives three quarters later asking how the box 4 total was arrived at.

The grain is one row per supplier document, not one row per line item. Some bookkeepers extract line-item data alongside the VAT-return work for spend analysis or category coding; that is a separate task with a different output. For a VAT-return support file, the document is the unit of work because the document is the unit of evidence — the supplier issues one invoice or one credit note, and one row in the worksheet records it.

This schema is the article's deliverable. The remaining sections fill it in: what content the supplier document has to carry before a row counts as deductible, which classification bucket each row lands in, how the totals roll into the current return boxes, how credit notes use the original-invoice reference column, how the rows are produced from PDFs at scale, and what to reconcile before the totals are entered in Tax For All.

Cyprus Invoice Content the Bookkeeper Must Verify Before Claiming Input VAT

A supplier invoice supports a Cyprus input-VAT claim only when the document itself carries the content a VAT invoice is required to have. Cyprus invoice requirements broadly track the EU VAT Directive's invoicing rules, and the Cyprus invoice fields for deductible input VAT are not negotiable: an incomplete document can be filed away as commercial evidence of a transaction, but it cannot anchor a box 4 entry until the supplier corrects it.

The checks the bookkeeper runs per supplier document are short and mechanical:

• Supplier identification. Legal name, address, and the supplier's VAT number with the correct country prefix. A row whose supplier VAT number is missing or malformed cannot be defended as a deductible-input row even when the rest of the invoice looks tidy.
• Customer identification. Your own business name, address, and VAT number on the face of the document where the supply requires it. Bills addressed to a personal name or a former entity name are a recurring source of unwinding under query.
• Sequential invoice number. Unique to the supplier's series; this is the lookup key any future reconciliation runs against.
• Issue date. And the tax-point date where it differs from the issue date. The tax-point date is what determines the period the row belongs in, not the date the document arrived in your inbox.
• Description of the supply. A clear statement of the goods or services supplied and the quantity or extent. "Services rendered" with no further description is a content gap.
• VAT breakdown. Net value, VAT rate, and VAT amount broken out — or, where standard rate does not apply, a clear statement of the VAT category (zero-rated, exempt, reverse-charge). A figure for "total" with no VAT line is a different document class and feeds a different bucket.
• Reverse-charge wording where applicable. When the supplier is invoicing under a reverse-charge regime, the document is supposed to say so on its face. The absence of that wording on a bill you believe should be reverse-charge is itself a content gap and needs raising with the supplier rather than assumed away.

When a row in the schema has a content gap, the working rule is to hold the row out of the input-VAT total, log the gap in the row's notes, and request a corrected document from the supplier. Pushing the row into box 4 anyway and unwinding it later under a query is more costly than the delay of waiting for the corrected invoice. The schema's VAT-rate or category column is designed to carry a "held — content gap" value alongside the standard treatments for exactly this reason; the row stays in the worksheet so it is not forgotten, it just does not flow into the period's totals.

Structured-evidence supplier documents change the mechanics but not the content checks. Where suppliers send PEPPOL or other e-invoice formats — common from Cyprus public-sector bodies and from larger EU vendors — the same VAT-content fields have to be present, but the verification is mechanical because the structured payload populates the schema columns directly. The fields can be read deterministically rather than scanned from a layout. For the deeper read on structured e-invoice evidence from Cyprus public-sector suppliers, the existing guide on Cyprus public-sector e-invoicing covers the routing and the payload shape.

An invoice that fails the content check does not lose its commercial validity. The transaction happened, the cost is real, the document evidences both. What it loses is its function as evidence for an input-VAT claim, and that function does not return until the supplier issues a corrected document with the missing content in place. The schema separates these concerns by keeping the row visible and the bucket conservative until the evidence is good.

Classifying the Mixed Input Stream

With the schema populated and the content checks done, each row needs to land in exactly one VAT-treatment bucket. This is the column the next section's box-mapping crosswalk reads from, so an undercooked classification step shows up later as a misposted return rather than a worksheet inconvenience. For Cyprus VAT return reverse charge purchases in particular, the bucket call is the whole game: get it wrong and the same row gets misposted on both the input and the self-assessed output sides of the return.

Treat the following six buckets as exhaustive for the worksheet's purposes. Every supplier document the bookkeeper handles in a normal quarter falls into one of them; ambiguous documents go into a "review" lane rather than getting defaulted into a bucket they might not belong in.

• Domestic standard-rated purchases from Cyprus suppliers. The default bucket for a CY-prefixed supplier billing at the standard rate. The schema's VAT amount is deductible (subject to the usual deductibility rules) and feeds box 4.
• Domestic reduced-rated or zero-rated purchases from Cyprus suppliers. Same supplier-side conditions, different rate. Each rate is recorded as itself — a 5% row is not a standard-rated row with a different number, because the rate column is what later proves the entry.
• EU acquisitions of goods from VAT-registered suppliers in other EU member states. A non-CY EU prefix on the supplier VAT number, a goods supply (movement of physical goods into Cyprus), and an invoice without home-country VAT charged are the cues. These rows self-assess: an output-VAT entry on the sales side, an input-VAT entry on box 4, and a value entry that also has to appear in box 11A.
• EU acquisitions of services from VAT-registered suppliers in other EU member states. Same supplier-side cues as goods, but the supply is services. These rows feed box 11B rather than 11A, and the box-mapping section walks through how 11B pulls through into the broader value-box totals.
• Imported services and other supplies subject to domestic reverse charge under Cyprus Article 11 categories. Imported services from non-EU suppliers fall here, as do domestic supplies in the categories Cyprus has put under reverse charge (construction services, scrap metal, and the other defined categories). These rows also self-assess on both sides of the return.
• Exempt, outside-scope, or non-deductible purchases. Genuinely exempt supplies, supplies for non-business use, and expense categories with blocked input VAT. The row stays in the worksheet — that is what makes the audit trail complete — but the VAT amount does not feed box 4.

The cues that distinguish one bucket from another come off the document itself. The supplier's country and the prefix on the VAT number are the first split: a CY prefix points domestic, another EU prefix points EU acquisitions, no VAT number points either non-VAT supplier or non-EU. The goods-versus-services nature of the supply is the second split for EU rows, since 11A and 11B treat them differently. The presence and exact wording of any reverse-charge statement on the document is the third — a CY-prefixed supplier's invoice carrying reverse-charge wording is a reverse-charge row even though the prefix would otherwise suggest standard domestic. The rate or category line on the invoice resolves the remaining cases.

For the EU acquisitions buckets, the supplier-side VAT-number validation and the recapitulative-statement obligation that pairs with intra-community supplies of goods and services sit alongside the VAT-return entry. The mechanics of the VIES side — VAT-number validity checks, monthly filing windows, and the XML upload — are covered separately in the existing guide on Cyprus VIES filing for intra-community acquisitions and supplies, and bookkeepers handling EU-acquisition volume should keep that workflow in step with the return preparation rather than running them as independent tracks.

For the imported-services and domestic reverse-charge buckets, the Cyprus Article 11 categories carry their own self-assessment mechanics that affect both the output and input columns of the same return. The category list, the conditions, and the worked treatment are covered in the existing guide on Article 11 reverse-charge treatment on imported-services supplier invoices; the present guide stops at the classification call and the schema row, with the bucket carried forward into the box-mapping step.

For the non-deductible bucket, the common pitfalls are the same as in most VAT jurisdictions: entertainment expenses, certain passenger-vehicle costs, and expenses without a business purpose. The point here is not an exhaustive list — that belongs in a tax-treatment reference, not a return-preparation worksheet guide — but a reminder that the schema's VAT-rate or category column has to accept "non-deductible" as a legitimate value alongside the rate codes. A non-deductible row that gets coded as standard-rated overstates box 4 and is the kind of error that surfaces at audit rather than at filing.

The working rule on uncertain rows is to flag rather than default. A row whose bucket is genuinely unclear from the document should not be folded into domestic standard-rated because that is the easiest call to make. It should be held in a review lane, escalated to the accountant where the treatment depends on facts the document does not surface, and posted only once the bucket call is defensible. The cost of a held row is a delay; the cost of a defaulted row is a misstatement.

Mapping Classified Totals Into the Current 1-11B Return Boxes

With each row in the worksheet now carrying a classification bucket, the box mapping is mechanical — sum the right column subsets into the right boxes and apply the cross-box arithmetic the return enforces.

In operational terms, boxes 1-5 carry VAT amounts and boxes 6-11 carry values excluding VAT. Box 1 plus box 2 equals box 3 (total output VAT). Box 3 minus box 4 equals box 5 (net payable or refundable). Boxes 11A and 11B carry the values of EU acquisitions of goods and services respectively and sum into the relevant value boxes for the EU-acquisition figures. The Cyprus input VAT box 4 is the destination for every deductible VAT-amount row across the classification buckets, and is where most of the schema's VAT-amount column lands.

One freshness call-out before the crosswalk. Some local guides and accounting-software help pages still describe the Cyprus VAT return as a 9-box process. That framing is out of date. The current return is structured 1-11B, and a worksheet built against the older layout will not align cleanly with what the portal accepts at entry. The Cyprus EU acquisitions boxes 11A 11B treatment in particular has no equivalent in the 9-box framing, which is one reason the schema in this guide tracks the goods-versus-services split as a separate column.

The purchase-side crosswalk reads as follows. Output-VAT boxes (1, 2, and the sales side of the return) are out of scope here and are covered when the bookkeeper compiles the sales-side worksheet for the same period.

Classification bucket	VAT-amount destination	Net-value destination
Domestic standard-rated and reduced-rated purchases	Box 4	Box 7
Domestic zero-rated purchases	No VAT amount	Box 7
EU acquisitions of goods	Box 4 (input side of self-assessment)	Box 7 and box 11A
EU acquisitions of services	Box 4 (input side of self-assessment)	Box 7 and box 11B
Imported services and domestic reverse charge	Box 4 (input side of self-assessment)	Box 7
Exempt, outside-scope, or non-deductible	Not in box 4	Treatment follows the bucket; genuinely non-business spend stays out of the return entirely

The table covers purchase-side destinations only. For EU-acquisition and reverse-charge rows, the self-assessed output side of the same transaction also feeds box 2 (output-VAT amount) and box 6 (net value), with the box 11B figure pulling through into box 6 for EU acquisitions of services as part of the EU-acquisition reporting. The sales-side worksheet for the period is where those output-side entries are compiled and is out of scope here.

A worked numerical example makes the mechanics concrete. Suppose the worksheet for a quarter contains a single domestic standard-rated invoice from a CY-prefixed supplier for €1,000 net plus €190 VAT (19% standard rate). The row contributes €190 to box 4 and €1,000 to box 7. That is the whole of its effect on the purchase side of the return.

Now suppose the same quarter contains an EU acquisition of services from a DE-prefixed supplier for €2,000, with no German VAT charged because the supply reverse-charges to Cyprus. The bookkeeper self-assesses Cyprus VAT at the applicable rate — €380 at 19%. The single supplier document produces, on the input side: €380 to box 4 and €2,000 to box 7 and box 11B. On the output side of the same return: €380 to box 2 and €2,000 to box 6, where box 11B pulls through into the box 6 figure as part of the EU-acquisition reporting. The single document touches box 2, box 4, box 6, box 7, and box 11B — which is exactly why the schema's EU-acquisition flag and goods-versus-services distinction earn their column.

After the totals are entered, three arithmetic checks confirm the return is internally consistent. Box 1 plus box 2 should equal box 3. Box 3 minus box 4 should equal box 5. Box 11A plus box 11B should equal the EU-acquisitions portion of the value boxes the bookkeeper recorded for the period. None of these checks substitutes for the worksheet-level reconciliations covered later, but each catches a different class of error: arithmetic, posting, and the EU-acquisition pull-through respectively.

The structural facts here — the box layout, the cross-box arithmetic, the 11A and 11B mechanics — sit in the official Cyprus VAT return completion guide. The schema and the crosswalk in this article are built to align with that source rather than the 9-box framing seen elsewhere. Keeping the official guide alongside the worksheet during the first one or two return cycles is good practice; once the schema is producing clean rows and the crosswalk is internalised, the official guide becomes the reference for the edge cases rather than the entry point.

Credit Notes as a First-Class Document Type

The most common mistake on the purchase side of a Cyprus VAT return is treating credit notes informally. A supplier issues a credit, the bookkeeper finds the underlying invoice, the row gets netted down, and the credit note itself disappears into the supporting documents folder without its own row in the worksheet. The arithmetic works for that single period; the audit trail does not.

A credit note from a supplier reduces input VAT in the period in which the credit falls, subject to the documentation rules. The worksheet treatment that holds up at audit is the one that records the credit note as its own row in its own period, with the original-invoice reference column linking the two documents explicitly rather than folding them together off the worksheet.

Before the row is recorded, the bookkeeper runs the same content checks as for an invoice, with three additions:

• All the content a Cyprus VAT invoice has to carry — supplier identification, sequential number, date, description of the supply, VAT breakdown — is also required on a credit note.
• The supplier identifies the document as a credit note on its face. A "corrected invoice" or "revised invoice" that does not state it is a credit note is a different document class and creates a different problem, usually requiring the original invoice to be cancelled and reissued.
• The document carries a specific reference to the original invoice it relates to. This last point is the load-bearing one. EU invoicing rules for credit and debit notes require a credit or debit note to carry a specific, unambiguous reference to the initial invoice and the details being amended — and Cyprus implements that baseline. A credit note without that reference is not a defensible reduction to a prior period's input VAT; it is an undocumented adjustment, and the schema row stays in the review lane until the reference is supplied.

In the schema, a credit-note row populates differently from an invoice row in five places:

• Document type is set to "credit note" rather than "invoice."
• Document number is the credit note's own sequential number, not the underlying invoice's.
• The original-invoice reference column is populated with the underlying invoice number. This is the only document class for which that column is mandatory; on every other row it is blank.
• Net value and VAT amount are recorded as negative figures, so the row subtracts from box 4 and box 7 totals when summed.
• The VAT-treatment bucket is inherited from the original invoice rather than reassessed. A credit against a domestic standard-rated invoice stays in the domestic standard-rated bucket; a credit against an EU acquisition of services stays in the EU acquisitions of services bucket and reverses both sides of the self-assessment. The credit note does not change the classification; it reverses the row inside it.

Two operational scenarios cover most cases.

In the simpler scenario, the credit note arrives in the same period as the underlying invoice. Both rows go into the worksheet, both feed the same box totals, the credit subtracts what the invoice added, and the net result on the return reflects only the residual. There is nothing special to do at the box-mapping step; the row-level negatives handle it.

In the harder scenario, the credit note arrives in a later period than the underlying invoice — usually when the invoice's period has already been filed. The bookkeeper does not amend the filed period. The credit-note row goes into the current period's purchase register and reduces the current period's box 4 and box 7 (and, for an EU-acquisition credit, the relevant 11A or 11B and pull-through values). The row's notes column carries a reference to the filed period for audit clarity. The supplier's credit and the bookkeeper's return treatment are aligned without re-opening anything.

Debit notes work the same way in the other direction. A supplier-issued debit note is an upward adjustment — additional consideration, missed VAT, or a correction in the supplier's favour. The same content rules apply, the same original-invoice reference is required, and the schema row carries positive net and VAT amounts that add to the current period's box 4 and box 7 totals. Debit notes are less common than credit notes in most AP streams, but the worksheet treatment is symmetric.

For AP teams processing credit notes at volume — the kind of operation where a single quarter brings in dozens of credits against earlier invoices and the original-invoice reference column is the only way to keep them straight — the practical mechanics of pulling those fields out of the credit-note PDF systematically are covered in more depth in the existing guide on credit-note fields and original-invoice references for AP extraction.

Producing the Worksheet From Supplier PDFs at Scale

Everything to this point assumes the worksheet exists. The SERP's default assumption is that someone is typing it. A bookkeeper with a quarter's worth of supplier PDFs and credit notes — a folder of perhaps 200 to 800 documents for a typical Cyprus SME, more for a wholesale or logistics operation — sits at the screen and keys the schema row by row. The audit trail at the end is good. The time cost is the problem, and it is the same time cost every quarter.

The extraction step removes most of that typing. A batch of supplier PDFs goes in: invoices, credit notes, EU acquisition documents, reverse-charge bills, mixed together. A structured spreadsheet comes out, with one row per document and the schema columns from earlier in this guide already populated, including the original-invoice reference column on credit-note rows.

A working prompt that produces the schema directly looks like this. Extract one row per supplier invoice or credit note, with these fields: supplier name, supplier VAT number with country prefix, document type (invoice or credit note), document number, issue date, tax-point date where separately stated, net amount, VAT amount, VAT rate or category, currency, reverse-charge wording if present, original invoice reference (mandatory for credit notes), and the source file name. For credit notes, prefix the document number with "CR-" and show net and VAT amounts as negative figures. Skip pages identified as email cover sheets, remittance advice, or statement summaries. One row per document.

That prompt is the worksheet specification translated into extraction instructions. The output is the populated schema — the reviewable support file the bookkeeper validates before the totals are entered in Tax For All. You can extract supplier invoice and credit-note data into a structured purchase-register spreadsheet once a quarter from the same saved prompt, and the same schema appears every time regardless of how many documents the batch contains. The country-agnostic mechanics — field schema, validation controls, and audit-trail design for turning supplier invoices into a VAT-return-ready working paper — sit underneath the Cyprus-specific schema here and are reusable across any jurisdiction whose return reads from a purchase register.

The product we build to do this — Invoice Data Extraction — uses a single prompt field with a file upload area. The interaction is the same as a modern AI chat: drop the documents in, write or apply the prompt, download the file. Where it diverges from a general-purpose AI tool is at volume. A batch can carry up to 6,000 mixed-format files (PDF, JPG, PNG), and single PDFs can run to 5,000 pages. The same prompt produces the same schema-aligned output — XLSX, CSV, or JSON — across every document in the job, which is what makes the audit trail consistent. Saving the schema prompt to the prompt library once means the next quarter's run starts from the same instructions rather than a fresh draft, and the row shape across periods stays comparable. Every row in the output carries a reference back to the source file and page number, so the evidence-reference column in the schema is populated directly rather than maintained by hand.

What the extraction step does and what the bookkeeper still owns are two different lists. The extraction step populates the schema rows: supplier identity, document type, dates, amounts, rates, the reverse-charge wording where it is on the document, and the original-invoice reference where the credit note states it. The bookkeeper still owns the VAT-treatment bucket for each row (because the document does not always state its bucket cleanly — a reverse-charge bill without explicit wording is still a reverse-charge bill, and only the bookkeeper makes that call), the deductibility judgment (entertainment, blocked categories, mixed-use spend), and the reconciliation of the worksheet against supplier statements and the accounting system before filing.

The extraction step also has hard boundaries it does not cross. It does not file the return in Tax For All. It does not calculate the Cyprus VAT return. It does not sync into accounting systems beyond the file export. It does not provide tax advice. The product produces the support spreadsheet; the bookkeeper or accountant validates the VAT treatment and submits the return.

Treated as part of the quarterly cadence, the extraction step changes the shape of the work rather than just the speed of it. The first time the prompt is written and saved, there is real design work in matching the field list to the schema and getting the credit-note rules right. From the second quarter onward, that work is done — the prompt sits in the library, the schema does not change, and the worksheet is produced from the documents in minutes rather than days. The bookkeeper's time moves from data entry into the classification call, the deductibility judgment, and the reconciliation. Which is where the bookkeeper's judgment is worth most.

Reconciliation and Handover Into Tax For All

The reconciliation step is what makes the worksheet defensible. The schema captures the right rows, the classification step puts each row in the right bucket, the box mapping rolls the totals to the right places — and none of that is worth much until three reconciliations confirm the worksheet matches the supplier-side reality, the bookkeeping system, and its own internal arithmetic. Tax For All Cyprus VAT return preparation lives or dies at this step. Most queries against a filed return resolve to something a reconciliation should have caught.

The three checks the bookkeeper runs before entering anything on the return:

• Supplier-statement reconciliation. Row totals per supplier should match the supplier's statement of account for the period. Timing differences are normal — an invoice issued by the supplier on the last day of the period but received in the next, a credit note crossing periods, an early-period invoice the supplier statement omitted — and each one should be explainable from the row metadata without reconstructing the row. Differences that are not explainable from timing point to a missing document, a duplicated row, or a supplier-statement error, and need resolution before the totals are entered.
• Accounting-system reconciliation. The schema totals per VAT-treatment bucket should agree with the equivalent totals in the bookkeeping system. Disagreements are usually one of three things: a supplier document was extracted into the worksheet but never posted in the accounting system; a row was misclassified in one place but not the other; or a credit note was netted in the accounting system but kept as its own row in the worksheet (or the other way around). All three are resolved by aligning the two records, not by annotating the difference.
• Internal box-arithmetic check. Box 4 should equal the sum of input-VAT amounts across the deductible rows. Box 7 should equal the sum of net values across those rows plus the non-deductible-but-in-scope rows that belong in the value boxes. Box 11A plus box 11B should equal the EU-acquisition portion of the value boxes and should pull through into the broader value-box totals as the box-mapping section described. This check is mechanical, but it catches the class of errors where a row was correctly classified and correctly summed but landed in the wrong destination column at the rollup.

When the three reconciliations agree, the handover into Tax For All is straightforward. The bookkeeper enters the validated box totals into the return form in the portal, attaches or retains the reconciled worksheet as the supporting evidence behind those totals, and files the return for the period. The portal is the filing channel. The worksheet is the audit trail. The two artefacts work together: the return as filed is what the tax authority sees, the worksheet is what the bookkeeper opens when a query arrives six months later and asks how box 4 was arrived at for that quarter.

The practical cadence: Cyprus VAT returns are typically filed quarterly through Tax For All, and the reconciled worksheet for the period is the artefact the finance team retains for that purpose. The retention horizon should match the period the tax authority can query under, which in most cases is multi-year — so the worksheet is not a one-quarter artefact, it is a per-period entry in a longer record.

The longer-run payoff of treating the worksheet as a first-class artefact rather than a one-off tab is that the next quarter starts at the document-collection step rather than the schema-design step. The schema is fixed. The classification taxonomy is fixed. The extraction prompt (if one is in use) is fixed. The box-mapping crosswalk is fixed. What changes from quarter to quarter is the set of supplier documents and the row-level judgment calls inside them. The audit trail compounds across periods — a Cyprus finance team a year into running this workflow can answer a query for any prior quarter from the same shape of evidence, which is what defensible VAT-return preparation looks like over time.