[BUG] Integration/inFakt — adapter drops the invoice currency, so a EUR invoice is booked as PLN

[norbert-kulus-blockydevs]

Problem / Context

The neutral invoicing command carries a currency:

// libs/core/src/invoicing/domain/types/invoicing.types.ts:486
currency: string;   // ISO 4217, single-currency invoice

The inFakt request type does not have a currency field at all:

// libs/integrations/infakt/src/domain/types/infakt.types.ts:50-81
export interface InfaktInvoice { … }   // no currency / kurs field

and infakt-invoicing.adapter.ts contains zero references to .currency — the string "currency" appears only inside comments about the groszy integer format (:232, :425, :686).

So command.currency is silently dropped. Amounts are sent as plain integers in the minor unit with no currency attached, and inFakt books them in the account's default currency (PLN). A EUR 811.37 invoice is issued as PLN 811.37.

Two things make this worse than an ordinary mapping gap:

• It is silent. No log, no validation, no business_failure. Nothing distinguishes it from a correct issuance.
• It propagates. inFakt relays to KSeF on the seller's behalf (see the Invoicing section of docs/architecture-overview.md), so an incorrect fiscal document clears the tax authority. A cleared document is not something OL can quietly re-issue.

Surfaced while reviewing #2050 / ADR-040, whose Non-goals section draws a hard line around fiscal currency handling. Independent of that PR.

Proposed Solution

1. Establish the contract. Determine from inFakt's API documentation how a document declares its currency — most likely an invoice-level currency field plus an optional rate, given that inFakt performs its own conversion server-side. Record the finding in the issue with a doc reference, since the current absence may be a genuine API limitation rather than an OL oversight.
2. If inFakt supports it — add the field to InfaktInvoice and map command.currency onto it. Verify against the sandbox that the issued document actually renders in that currency.
3. If inFakt does not support it — reject issuance for any currency other than the account's default with a terminal business_failure and an explicit reason, rather than booking in the wrong units. A refused document is recoverable; a cleared wrong one is not.
4. Cover the sibling write paths — issueCorrection and markPaid go through the same async task endpoints and need the same treatment.

Run the same audit against the Subiekt nexo adapter (libs/integrations/subiekt/), which implements the same InvoicingPort. If it has the same gap, file it separately rather than widening this issue.

Classification

Type: Integration
Layer: Infrastructure
File(s):

• libs/integrations/infakt/src/infrastructure/adapters/infakt-invoicing.adapter.ts
• libs/integrations/infakt/src/domain/types/infakt.types.ts:50-81

Dependencies

• None. Independent of Order-time FX rate snapshot + reporting-currency stamping #2049 / ADR-040.

Assumptions

• Shipped inFakt accounts are PLN-denominated and every order exercised in testing so far was PLN, which is why the gap has not surfaced in practice.
• IssueInvoiceCommand.currency is populated correctly upstream (it is echoed from the order), so the defect is confined to the adapter boundary.

Acceptance Criteria

• Whether inFakt's API accepts a document currency is established and documented in the issue, with a link to the relevant API docs
• If supported: command.currency reaches the request and the issued sandbox document renders in that currency
• If unsupported: a non-default-currency order fails terminally with an explicit reason instead of being booked in the wrong currency
• issueCorrection and markPaid are covered by the same behaviour
• A unit test asserts a non-PLN command either carries the currency or is rejected — never silently booked as PLN
• The Subiekt adapter is checked for the same gap and the result recorded (separate issue if it applies)
• Tests added or updated for non-trivial logic
• No architecture boundary violations (CORE ↔ Integration)

[norbert-kulus-blockydevs]

API contract finding: inFakt does support a document currency

Source: inFakt's published API v3 reference, Definicja faktury VAT field table - https://github.com/infakt/API/blob/master/readme.md#definicja-faktury-vat (rendered at https://docs.infakt.pl/ and https://www.infakt.pl/developers/).

Field	Type	Reference description	Readonly?
currency	string	Waluta (domyślnie PLN)	No - the reference marks readonly fields explicitly (net_price, tax_price, gross_price, exchange_rates_data, amount_in_words, ...) and currency carries no such marker
exchange_rates_data	object	Dane kursów walut	Yes (readonly)
vat_exchange_date_kind	string	Rodzaj daty kursu - wymagane przy walucie obcej	No (documented in the margin-invoice table; the field is also returned on VAT invoices)

So the field exists, it is invoice-level, and OL sends no exchange rate: inFakt performs the conversion itself and reports the resulting rate back on the read-only exchange_rates_data block.

Confirmed against the live sandbox (https://api.sandbox-infakt.pl/api/v3, read-only GETs, 2026-08-14):

• GET /invoices.json - every entity carries "currency": "PLN" immediately after number, and vat_exchange_date_kind is present (null on the PLN documents on file).
• GET /corrective_invoices.json - the corrective resource carries currency too, so a correction declares its own currency rather than inheriting one implicitly.
• currency is selectable via the fields= subset, i.e. it is a first-class field, not a computed extra.
• All 68 sandbox documents are PLN, which matches the issue's assumption that the gap never surfaced in practice.

Two things the docs do not settle, and which a read-only probe cannot settle either:

1. Whether a foreign-currency VAT invoice additionally requires vat_exchange_date_kind. The reference documents it as "required with a foreign currency" only in the margin-invoice table; its allowed values are not published. If inFakt does require it, the request is rejected with a 422 - which is the safe direction (a loud terminal rejection, not a silently mis-denominated document).
2. Whether the seller's account is permitted to settle in a given currency. inFakt owns that rule and enforces it server-side.

Consequence for the fix

Branch (2) of the proposed solution applies: currency is added to InfaktInvoice / the corrective request type and stamped on every write. The one deviation from a plain pass-through is that a blank or malformed code is refused with a 422 before the POST rather than omitted - because omitting the field is exactly what inFakt reads as "use the account default", and it answers 200/201 either way, so omission is indistinguishable from success.

Write-path confirmation (issuing a EUR sandbox invoice and checking the rendered document's currency) is still outstanding and is called out in the PR as a manual step.

[norbert-kulus-blockydevs]

Confirmed live: a EUR invoice issues as EUR

Follow-up to the API-contract comment above, which was based on the published reference plus read-only GETs. The write path is now confirmed too.

One throwaway document was issued against the sandbox (https://api.sandbox-infakt.pl/api/v3) with the exact payload shape the fix produces: invoice.currency stamped, payment_method: 'cash', numeric client_id, one integer-minor-unit line. POST /invoices.json returned 201, and an independent GET /invoices/{uuid}.json reads back the same values:

Field	Value
currency	"EUR"
net_price / tax_price / gross_price	65965 / 15172 / 81137, i.e. 811.37 EUR gross - the exact figure from the issue description
amount_in_words	"osiemset jedenaście EUR 37/100"
vat_exchange_date_kind	"vat", populated by inFakt server-side
status	draft

So currency is genuinely writable, and the amount is denominated in EUR on the document itself rather than being reinterpreted as PLN. This closes the acceptance-criteria item "the issued sandbox document renders in that currency".

Two of the open questions from the earlier comment are settled by this run, one is not:

• vat_exchange_date_kind is not a required request field. inFakt defaulted it to "vat" for a foreign-currency VAT invoice with no input from OL, so the adapter does not need to send it.
• This sandbox account was permitted to settle in EUR with no extra configuration, so no per-currency account gate fired. It remains inFakt-side policy, and another currency or another account can still be refused.
• The applied exchange rate was not observable. exchange_rates_data was absent from both the create response and the read-back while the document sits in draft.

Scope of the run: exactly one document, deliberately left in draft and not submitted to KSeF (no send_to_ksef call), so nothing was filed with the tax authority. It is identifiable in the sandbox by its line name OL-2103-CURRENCY-TEST throwaway (do not book) and external_id: ol-2103-eur-currency-probe. No correction, mark-paid, email or delete was run against it, so the issueCorrection currency behaviour remains covered by unit tests only.