Closing the OSS quarter: controls and corrections in billing

Pulling an OSS return out of a billing system is the easy part. The hard part comes in the weeks after: a credit note touches a quarter you've already filed, a customer adds their VAT ID after the fact, a usage event from 30 September arrives on 2 October. Without fixed rules for those cases, someone ends up correcting numbers in a spreadsheet instead of deriving them from invoices.

This article covers the quarter close: deadlines, cut-off, reconciliation and the two most common correction cases. What OSS covers, how the EUR 10,000 threshold counts, which location evidence to keep and which tax fields every invoice line carries are covered in the companion article on OSS and the billing data model. The fields tax_scheme, supply_country and corrects_line_id from that piece are assumed here. Examples use a seller registered for OSS in Germany.

The calendar: return and payment by month end

In Germany the quarterly OSS return goes to the BZSt within one month after the quarter ends (§ 18j UStG), which gives four fixed dates:

Two details on the BZSt's OSS page are easy to miss. The payment has to reach the federal treasury by the same month end; filing alone isn't enough. And a quarter with no OSS sales still needs a return, a so-called nil return. For a B2B SaaS business with a handful of consumer customers, an empty quarter is realistic, and that's precisely when the date gets missed, because no report flags anything. Set the four dates up as tasks that are created regardless of revenue.

The cut-off: which lines belong in the quarter

A close needs one unambiguous rule for which invoice lines fall into the quarter. Agree once with your tax adviser which timeline applies to your services. After that it's configuration, and each line has exactly one quarter. Whether the line was created before or after the export must not change that.

Usage-based pricing adds late events. An event from 30 September can arrive days later because of a queue backlog, a batch upload or an error on the customer's side. What works is a short, fixed grace window after quarter end during which usage-based billing still accepts events for the old quarter. After that, the quarter is locked. An event that arrives later produces its own correction line pointing to the original quarter. It doesn't quietly change an invoice that has already been finalised.

Drafts never go into the return, even if they were created on 31 March and only finalised on 3 April. What counts is the final document.

Three totals that have to agree

Before filing, reconcile the same number from three sources, per member state and VAT rate:

1. the sum of invoice lines with tax_scheme = OSS_EU in billing,
2. the balance of the OSS VAT accounts in the general ledger, for example from your DATEV export,
3. the figures in the draft return.

One difference is expected and shouldn't be written off: FX, because the return uses the ECB rate for the last day of the quarter while your ledger probably booked at the invoice-date rate. So reconcile foreign currencies in their original currency first, then document the euro gap as an FX difference. Any other difference has a cause in specific lines and gets fixed there, not adjusted in the total.

Three queries find most of those causes:

• Lines with customer_status = CONSUMER whose customer now has a verified VAT ID. These are candidates for the case further down.
• Lines marked BUSINESS_VERIFIED with no stored validation record. They shouldn't slide into reverse charge unchecked.
• Lines whose supply_country doesn't match the linked evidence record.

A credit note for a quarter you've already filed

A walkthrough with numbers. On 14 August 2026 a seller invoices a private customer in Lyon EUR 1,000 net for an annual plan. The line carries OSS_EU, FR and the French standard rate, and it's in the Q3 return filed at the end of October. On 3 November the customer, who has since moved to Brussels, cancels and gets EUR 400 net back pro rata.

The broken path: the credit note is treated like a new invoice. It reads the country from the current customer profile and the quarter from its own date. The Q4 return shows minus EUR 400 for Belgium, where there was never a sale, and France stays EUR 400 too high for Q3.

The correct path: the credit note line points to the August line via corrects_line_id and inherits scheme, country, rate and original quarter from it. Where the customer lives today doesn't matter. The OSS return has a separate section for corrections to earlier periods, and the reduction goes there as a correction for France, Q3 2026, submitted with the next return. You don't reopen the Q3 return itself. The Commission's OSS guidelines and explanatory notes are the reference if your adviser wants the official wording.

For the system that means one hard rule: a credit note without a link to an original line doesn't get finalised. Goodwill credits with no underlying supply are a different transaction and need a deliberate decision on how they're treated for VAT.

A late VAT ID: switching from OSS to reverse charge

A self-service customer in France bought in Q3 without a VAT ID and was billed as a consumer through OSS. In November they add a VAT ID, and validation succeeds.

For new invoices from the successful check onwards, the system treats the customer as a business under reverse charge. The invoice carries the reverse charge wording, and the sale goes into the EC Sales List instead of the OSS return. That only works if the check runs at the right moment and its result is stored, as described in the article on automating VIES checks.

The old invoices are harder. Whether they get corrected is a case-by-case tax decision the system must not make silently. Re-running the tax rules over old lines is therefore off limits. If finance decides to correct, two new documents are created: a credit note against the OSS invoice, which goes into the next OSS return as a Q3 correction, and a new reverse charge invoice. Both reference each other, and the approval is recorded with a name and a date.

Closing the quarter in an order that holds

1. Wait out the grace window for usage events, then lock the quarter.
2. Finalise or discard any open drafts for the quarter.
3. Run the three reconciliation queries and resolve every hit.
4. Reconcile billing, ledger and draft return per country and rate, showing FX differences separately.
5. Collect corrections to earlier quarters from every credit note whose original quarter is before the current one.
6. File the return, even at zero, and pay by month end.
7. Store the return together with the list of underlying invoice lines as a frozen close snapshot.

After step 7 the quarter only changes through new documents that show up as corrections in the next return. Kontier locks billed periods in its European billing infrastructure and keeps credit notes linked to their original line and quarter.