🚩 Refunds exclude VAT: corrective invoices and FluentInvoice roadmap for 2027

Following up on our earlier invoicing feedback, we reproduced a refund issue on staging with FluentCart Core 1.7.0. No imported orders or real funds were involved.

TL;DR

• A product-selected refund excludes exclusive VAT and prevents entering the full amount paid.
• Our €12.10 test required two local refund operations: €10 + €2.10.
• We also need clarity on separate corrective invoices and FluentInvoice’s scope and timeline.

1. Refund calculation: steps to reproduce

Setup: one product, €10 base + €2.10 VAT = €12.10 paid.

1. Open Refund. The product is automatically selected.
2. The refund amount and maximum are both €10.
3. Enter €12.10. The field immediately resets to €10.
4. Refund €10. The order becomes partially refunded, with €2.10 net paid.
5. Reopen Refund. With no product selected, €2.10 is now available. Refund that amount to reach €12.10 refunded and a zero balance.

Expected: refunding the complete product should include its VAT, allowing €12.10 in one operation.

Test limitation: we completed the two operations using an offline test payment. These verify local calculations and records, not movement of funds. We are not reporting the offline gateway’s inability to send money back as a bug.

For integrations generating one corrective document per refund event, two operations could also produce two documents for one cancellation unless explicitly reconciled.

2. Customer documents after a refund

• My Account’s View Receipt / Invoice still downloads the original positive document.
• The order confirmation shows the refund and remaining balance.
• Our PDF template is customized, so its missing refund line alone is not evidence of a core bug.

Preserving the original invoice is appropriate. The separate corrective document we need is already described in our earlier request for proper credit notes / corrective invoices, including independent numbering, a reference to the original invoice, corrected base/VAT amounts and customer access.

The default refund_notice references the original order number/date and cumulative refunded amount. Can it represent individual corrective documents with independent numbering, rather than only a refund notice?

Spain requires a specific separate series for corrective invoices, e.g. FR-0001 (Articles 6 and 15). National rules may vary for some cases.

3. Questions for the team

• Refund calculation: is the VAT issue above scheduled for correction?
• FluentInvoice: will it provide corrective invoices, independent sequences and customer access? What will remain in Core or Pro?
• Gateway status: in a separate test, a blocked Stripe refund request failed while a local refund transaction appeared as Refunded. How should integrations distinguish a local/manual record from a gateway-confirmed refund?
• Compliance readiness by November–December 2026: will FluentInvoice provide a compliant Spanish invoicing solution, including VERI*FACTU, or a supported integration by then? Extension points alone would still leave stores needing an implementation. Please also clarify the scope for other national requirements.
• Mandatory producer declaration: if FluentInvoice is intended to serve as a EU invoicing system (eg.: for Spain), will WPMN provide the required "declaración responsable", accessible in the product for each version? If compliance depends on another provider, who will certify the complete solution and its components? Spain uses a producer’s declaration, not prior AEAT approval (AEAT guidance).
• Planning: what scope and delivery timeframe can stores realistically plan for in 2027? If corrective invoicing is outside your scope, should we build an external/custom integration now?

Why the timing matters

We are less than three months from 2027, and implementation takes time. Spain’s current adaptation deadlines are January 2027 for corporate income-tax taxpayers and July 2027 for other covered taxpayers, including self-employed professionals (AEAT guidance). Other countries have their own rules and dates.

Without a clear, usable solution by November–December, I fear many Spanish stores will choose another paid invoicing solution for compliance. Developing and certifying a custom adaptation is not realistic for most small businesses. Once those integrations are in place, a FluentCart migration may be deferred until January 2028 or later (if) simply because of implementation costs and planning cycles.

For accuracy, the VERI*FACTU commitment lasts until the end of the calendar year in which reporting begins once the rules apply. It is not a minimum twelve-month commitment and does not itself require staying with the same software provider (AEAT guidance).

We really like FluentCart’s flexibility. A clear scope, responsible provider and timeline would help us decide whether to migrate with native invoicing, use a supported external integration, or simply wait (if) to 2028.

Related discussions

• Corrective invoices and separate numbering
• EU migration: invoice documents and numbering
• Receipt vs Invoice: customer downloads and templates