---
status: Accepted
date: 2026-09-30
applyTo:
  - "Fuchs_Database/dbo/Functions/fds__fn_invoiceDate.sql"
  - "Fuchs_Database/dbo/Functions/fds__r_getBalanceThisMonth.sql"
  - "Fuchs_Database/dbo/Stored Procedures/fds__getDatevExports.sql"
  - "Fuchs_Database/dbo/Stored Procedures/fds__getInvoices_list*.sql"
  - "Fuchs_Database/dbo/Stored Procedures/fds__getFDSDocument.sql"
  - "Fuchs_Database/dbo/Stored Procedures/fds__getReportDocument.sql"
  - "Fuchs_Database/dbo/Stored Procedures/fds__getRequest_details.sql"
  - "Fuchs_Database/dbo/Stored Procedures/fds__r_*.sql"
  - "Fuchs_Database/dbo/Stored Procedures/fds__*Reminder*.sql"
  - "Fuchs/code/InvoiceDates.cs"
  - "Fuchs/Services/ReminderService.cs"
  - "Fuchs/Services/*DraftEditService.cs"
supersededBy: ""
---

# 0035 — The invoice date is `DateFinalized` everywhere

## Context

ADR 0032 made `DateFinalized` the invoice date for the PDF, the e-invoice (BT-2) and the number
sequence, and introduced backdating (which only moves `DateFinalized`). Everything else — invoice
lists, revenue reports and charts, the DATEV export, document lookups, the request details — still
dated and grouped invoices by `DateCreated`, the moment the *draft* was created. A backdated invoice
therefore showed September on the document and October in every list, report and in DATEV, and any
invoice drafted in one month and finalised in the next had the same split.

## Decision

- **One invoice date, everywhere:** the German calendar day of `DateFinalized`, falling back to
  `DateCreated` only for drafts. Both columns are stored in UTC.
- **One implementation per side:** `[dbo].[fds__fn_invoiceDate](DateFinalized, DateCreated)` in SQL and
  `InvoiceDates.IssueDate` in C#. No proc converts or picks the date itself.
- Applies to: the DATEV export (period filter, `Belegdatum`, `Belegfeld 2`), the invoice lists
  (`fds__getInvoices_list`, `list2`, `list_vario`: period filter, `Belegdatum`, `DateOfCreation`,
  ordering, overdue fallback), the revenue reports (`fds__r_*`: year/month filters and grouping,
  `fds__r_getBalanceThisMonth`), document lookups (`fds__getFDSDocument`, `fds__getReportDocument`),
  `fds__getRequest_details` (new column `InvoiceDate`, shown in the request's invoice list), and the
  invoice date shown in reminders (`fds__prepReminder`, `fds__createReminder`, `fds__getReminder`).
- **Reminders use the same rule for their own date:** the reminder PDF's date is the reminder's
  `DateFinalized` (German day), draft: `DateCreated`.
- **No transition safeguard.** The switch applies to all periods, past and future; already exported
  DATEV periods are not reconciled (confirmed by the business owner, 2026-09-30).
- `DateCreated` keeps its meaning — the creation timestamp of the row — and is still returned where
  callers read it as such. Draft previews stamp it with `DateTime.UtcNow` to match the stored column.

## Consequences

- Reports and exports for a past period can differ from what they showed before this change: an
  invoice drafted in month M and finalised in M+1 now counts in M+1.
- Filters on the invoice date are not SARGable (they were not before either: `CAST(DateCreated as date)`).
  Acceptable at the current table size; an indexed computed column is the follow-up if it matters.
- Any new list, report or export that shows or groups invoices by date must use
  `fds__fn_invoiceDate` — never `DateCreated` or a raw `DateFinalized`.

## Alternatives considered

- **Keep `DateCreated` in lists/reports, `DateFinalized` only on documents** — rejected: the same
  invoice would carry two dates, and backdating would never reach the books.
- **Transition safeguard for already exported DATEV periods** — rejected by the business owner.