# Filings

> Filing periods, filing-ready tax reports generated from the ledger, and how a person or an authorized agent submits and pays each return.

Once your entity is registered in a regime, it has to file returns there, usually every month or quarter, and pay the tax it collected. Ownrecord prepares everything for each return. A person on your team, or an agent you've authorized, submits it to the tax authority and pays.

## Filing periods

Ownrecord creates a **filing period** for each regime you're registered in (or in a grace period for), following that regime's filing rules: how often you file and when each return is due. For example, the EU One-Stop Shop return is quarterly and due at the end of the month after the quarter. The rules come from the tax knowledge base, never from code, so a change in the law is a data change.

A daily job creates the periods, from the one containing the registration's effective date up to the current one, in both [modes](https://ownrecord.io/docs/concepts/test-and-live-mode.md). A period is made of whole days in your entity's time zone, the same days its invoices are dated in, and is due at 23:59:59 local time on the due date. A period covers every brand of the entity.

### Filing schedules

Some filing rules depend on the taxpayer. The UK, for example, gives each business its own VAT quarters (ending in March, April or May and every three months after) and makes returns due one calendar month and seven days after each quarter; Switzerland settles monthly on request. Where the knowledge base can't say it for you, set the **filing schedule** of the registration on the Filing page or with `filing_periods.set_schedule`:

- the **frequency**: monthly, quarterly or yearly;
- the **stagger**: a month a period starts in (February for quarters ending in April, July, October and January; April for a year from April to March);
- the **due rule**, when the filing rules give none Ownrecord can compute: a number of days after the period, the last day or a given day of the next month, or months and days after the period (the UK's is one month and seven days).

The periods are created at once. A staggered period is named by its first and last month, such as `2026-05..2026-07`. Once periods exist, a new schedule has to keep them whole: their first start and last end must be boundaries of the new schedule (`filing_schedule_conflict`). `filing_periods.schedules` lists each registration's schedule, where it comes from, why no periods exist when none can be generated, and its **next filing**: the earliest period still to file and its due date, kept on the registration.

A filing period moves through these states:

| State       | What happened                                                                                                   |
| ----------- | --------------------------------------------------------------------------------------------------------------- |
| `open`      | The period is running, or has ended and waits to be locked.                                                     |
| `locked`    | Someone on your team locked it once it was over.                                                                |
| `prepared`  | The report was generated and reconciles with the ledger. You can prepare it again until you submit it.          |
| `submitted` | The return was filed, and its reference is recorded, with the portal's confirmation if you upload it.           |
| `paid`      | The tax was paid, the payment reference is recorded, and the ledger moved the tax from tax payable to the bank. |

A refund or credit note issued after a period is over doesn't change that period: it is dated when it is issued and goes into a later return as a **correction** of the original period.

## Reports

Reports are generated from your ledger and invoices, never from processor data. Each regime gets the report it needs, chosen from the regime:

| Report                         | Regimes                                                | Currency                |
| ------------------------------ | ------------------------------------------------------ | ----------------------- |
| EU One-Stop Shop return        | `EU_OSS_UNION`, `EU_OSS_NON_UNION`                     | EUR                     |
| EU domestic VAT return         | an EU member state's own regime, such as `HR_DOMESTIC` | the filing rules' (EUR) |
| UK VAT return                  | the UK's regimes, such as `GB_VAT_NETP`                | GBP                     |
| Swiss VAT return               | Switzerland's regimes (with Liechtenstein)             | CHF                     |
| US sales tax return            | `US_SALES_TAX:{state}`                                 | USD                     |
| VAT/GST return (other regimes) | everything else, such as `NO_VOEC`                     | the regime's            |

Every report has the period's **totals** in the filing currency (taxable amount and tax of the period's own sales, corrections of earlier periods, the amount to pay and the amount the authorities refund), its sections, the exchange rates it used and the [reconciliation](#reconciliation-with-the-ledger). Credit notes count negative. A credit note for a sale of the same period reduces that period's rows; one for a sale reported in an earlier return is a **correction** of that period, at the original rate. Ownrecord doesn't keep purchases, so input tax isn't in the reports: add it in the portal.

### EU One-Stop Shop

- **Supplies** per member state of consumption and VAT rate: taxable amount and VAT in EUR.
- **Corrections** per original period and member state: the VAT of credit notes for supplies reported in an earlier return.
- **Balances** per member state: supplies plus corrections. The amount to pay is the sum of the positive balances; a member state with a negative balance refunds it, it isn't offset against the others.
- **Amounts by document currency**, with the exchange rate used, as an audit trail.

Amounts in other currencies are converted at the ECB reference rate of the period's last day, or of the next publication day when none was published that day. Corrections are converted at the corrected period's rate. The XML file some member states' portals accept isn't generated: download the CSV or XLSX and enter the figures in the portal.

### EU domestic VAT return

- **Domestic supplies** per VAT rate, **corrections** of earlier periods per original period and rate, and the **return values by rate**: supplies and corrections together, as the return's rate boxes take them.
- **Supplies not charged with VAT**, by treatment (exempt, not taxable).
- The **EC Sales List** (recapitulative statement): per member state and customer VAT ID, the value of the services you supplied to businesses in other EU countries that pay the VAT themselves (reverse charge), with corrections of earlier periods. The VAT ID and name come from each invoice; a credit note uses its original invoice's. It is part of the return of your home country's regime only.

### UK VAT return

The **nine boxes**: box 1 is the VAT of the period's sales and of credit notes, box 3 adds box 2, box 5 is the difference between boxes 3 and 4 (the totals say whether you pay or reclaim it), and box 6 is the value of your sales in whole pounds: sales at any rate, zero included, and exempt sales, credit notes deducted. Sales where the business customer accounts for the VAT (reverse charge) aren't in box 6. Ownrecord sells services and doesn't keep purchases, so boxes 2, 4, 7, 8 and 9 are 0: add your purchases in the portal. Sales by rate, credit notes for earlier periods and the sales not charged with VAT are listed too. HMRC's Making Tax Digital submission isn't part of Ownrecord yet.

### Swiss VAT return

The **turnover**: the total consideration (box 200), the taxed turnover and the tax; the **turnover and tax by rate**, credit notes included; the supplies per jurisdiction (Switzerland and Liechtenstein) and rate, corrections and turnover not charged with VAT, in CHF.

### US sales tax return

Per state: **gross sales** (every sale into the state: taxed, exempt, and sales made before you collected there), **taxable sales**, exempt and other sales, and the **sales tax**; the tax per rate; refunds of sales reported earlier as corrections; and the balance per state. Ownrecord charges state rates only, so there are no locality rows.

### Other regimes

Per jurisdiction and rate: the **taxable amount and tax** of the period's sales in the regime's currency, corrections by original period, the tax due per jurisdiction and the sales not charged with tax.

### Exchange rates

Except for the EU One-Stop Shop, amounts in other currencies are converted as the regime's filing rules say: at the ECB reference rate of the period's last day when the rules name it, otherwise at the ECB rate of each document's tax-point date (that day's rates, or the last ones published before it), which is when most laws convert. A credit note uses its original invoice's date, so it reverses exactly what was reported. Where the law names another publisher's rate (a national bank's, customs', a market rate), the ECB rate of the same date stands in for it; the report says which rule it used. Each row is summed exactly per currency and date and rounded once, to the minor unit.

**Sales made during a grace period** are reported in the first return after the registration: the return of the period that contains the registration's effective date. A period that ends before that date has nothing to report.

Each report is stored with the period and as **CSV** and **XLSX** files you download from the period's page (`filing_periods.report` returns the CSV's content over the API too).

## Reconciliation with the ledger

Every report includes a **reconciliation section**: per jurisdiction and currency, the report's tax compared with the movement of the regime's tax payable accounts in the [ledger](https://ownrecord.io/docs/concepts/ledger.md) for the period, including tax collected during a grace period. They must match to the cent. If they don't, no report is stored, and `filing_reconciliation_failed` lists the documents that differ: each invoice, credit note or ledger transaction with the report's and the ledger's tax. Correct the ledger or the documents, then prepare the period again.

## Paying

When you mark a return paid, the ledger posts `Dr tax_payable / Cr bank` for the tax the report reconciled, per jurisdiction, one transaction per currency. Jurisdictions with a negative balance aren't part of the payment.

## Deadlines

The filing calendar (`filing_periods.calendar`) shows every due date across your entities and regimes. Ownrecord reminds your tax managers and finance team 14, 7 and 2 days before each one, until the return is submitted: the `FILING_DUE_14`, `FILING_DUE_7` and `FILING_DUE_2` [alerts](https://ownrecord.io/docs/concepts/alerts.md), each once per period.

## Who files

Ownrecord doesn't log into government portals or submit returns itself. For each period:

1. **Prepare:** lock the period and generate the report.
2. **Submit:** file the return in the authority's portal before the due date, using the report files, then record the return's reference and the portal's confirmation.
3. **Pay:** pay the tax and record the payment reference.

Locking, submitting, marking paid and setting a filing schedule are compliance actions: when an agent does them, your approval policy applies; by default, a person must approve. Preparing a report is a write action an agent can do on its own. Ownrecord also records who is legally allowed to file for each entity in each jurisdiction, such as an employee, a tax representative or a firm with power of attorney. See [Building an agent on Ownrecord](https://ownrecord.io/docs/guides/building-an-agent.md).

## Events

`filing_period.created`, `filing_period.locked`, `filing_period.prepared`, `filing_period.submitted`, `filing_period.paid` and `filing_period.due_soon`; setting a filing schedule sends `registration.updated`. See the [event catalogue](https://ownrecord.io/docs/reference/events.md).
