Accounting software in Luxembourg: the four constraints that decide.

Why the question is not which software is best

The question almost always comes out as which tool is best. That is the wrong way in. In Luxembourg, accounting software is not judged on its interface or its feature list but on its ability to produce four deliverables imposed by separate texts: a trial balance compliant with the standard chart of accounts, a data set that can be filed on eCDF, a FAIA file on request from the tax authority, and a structured invoice for public-sector customers.

These four requirements do not overlap. A tool can map the standard chart of accounts perfectly and still prove incapable of producing a usable FAIA. Another can export a clean FAIA and know nothing of the presentation eCDF expects. Compliance is not a global attribute of the vendor. It is the outcome of four independent tests on one precise version, in one precise configuration.

That is why we publish no league table. A fixed ranking would be wrong within twelve months: frameworks change, versions succeed one another, and two clients of the same vendor can get opposite results depending on how their chart of accounts was initialised. The only method that holds is to test the four outputs on your own entries before signing.

The standard chart of accounts: who is actually in scope?

The Grand-Ducal Regulation of 12 September 2019 sets the content of the standard chart of accounts, on the basis of article 12 of the Commercial Code. It applies from the first financial year opened after 31 December 2019, which today covers every open financial year for the entities concerned.

The scope is narrower than people assume. It captures sole traders, Luxembourg commercial companies, Luxembourg branches of foreign companies and European economic interest groupings established in Luxembourg. It leaves out, among others, entities preparing their accounts under IFRS, special limited partnerships, insurance and reinsurance undertakings, financial sector professionals supervised by the CSSF, undertakings for collective investment and securitisation companies. Sole traders with annual turnover below 100,000 euros are also outside the scope.

The practical implication is direct: before ruling out a tool because it does not know the standard chart of accounts, confirm that you are subject to it. A private equity SCSp or an IFRS preparer does not carry the same requirements as a commercial SARL. We always start with that scope test, because it immediately eliminates or reinstates part of the shortlist.

What must the software produce for an eCDF filing?

Since 1 January 2020, VAT returns and recapitulative statements must be filed by electronic file transfer on the eCDF platform. The Grand-Ducal Regulation of 26 October 2019 removed the paper route for all taxable persons and non-taxable legal entities identified for VAT, whatever the filing frequency, monthly, quarterly or annual.

Annual accounts follow the same logic. Financial data is transmitted in structured form through eCDF, then attached to the filing made with the Trade and Companies Register. In practice, the software must be able to produce a trial balance in which each account maps unambiguously to the expected nomenclature, rather than a free-form export someone will rework by hand.

That is exactly where the hidden cost sits. Software that does not feed eCDF does not prevent filing: it moves the work onto manual re-entry, every month for VAT and once a year for the accounts. The annual cost of that re-entry often exceeds the licence saving, and it introduces a risk of divergence between the figures filed and the figures booked. How the platform works, LuxTrust access and the common errors are covered on our dedicated eCDF page.

FAIA, the export nobody tests before the audit

The AED computerised audit file, known by the acronym FAIA, is an XML file derived from the OECD SAF-T standard. It restates in standardised form the chart of accounts, the entries, the counterparties, the invoices and the stock movements for a given period. The schema in force is FAIA 2.01, available in a full version and two reduced versions depending on how integrated the accounting system is.

The obligation flows from article 70, paragraph 3, subparagraph 2 of the VAT law, as amended by the law of 19 December 2008. The rule is easy to state: where the books and records that must be communicated to the administration exist in electronic form, they must be provided on request in a legible and directly intelligible form. Any taxable person running a computerised accounting system must therefore be able to deliver its data electronically.

The difficulty is one of timing. The request arrives during an audit, with a short response window. That is the moment a business finds out whether its tool generates an accepted file, or an XML that is incomplete, unbalanced or stripped of its counterparties. Rebuilding a FAIA after the fact, across several financial years, costs incomparably more than checking the export once, calmly, in advance.

Our first qualification test is therefore always the same: generate a FAIA on one real month and inspect it. A vendor that shows a FAIA tick box on its datasheet has proved nothing until the file has been opened, validated against the schema and reconciled to the trial balance.

Can you still keep the books on a spreadsheet?

Legally, no text requires buying a package. Bookkeeping on a spreadsheet is not unlawful in itself. In practice it becomes untenable as soon as the entity is VAT-registered and handles a meaningful volume of documents, for one precise reason: a spreadsheet produces no FAIA.

The reasoning deserves to be set out coldly. While the books stay on a spreadsheet, they are not a computerised accounting system in the sense of the VAT law, and the export question does not arise in the same terms. But neither do they produce a reliable audit trail, a numbering sequence or a lock on closed periods. During an audit the burden of proof shifts entirely onto paper vouchers and file consistency, which lengthens and hardens the review.

The switching point rests on three signals rather than on a turnover figure: moving to monthly VAT returns, the appearance of intra-Community transactions requiring recapitulative statements, and crossing roughly a hundred documents a month. Past that point the spreadsheet no longer costs less. It simply costs elsewhere, in rework time and in audit exposure.

E-invoicing: what is in force and what is not

Two regimes must be kept apart, and sales pitches rarely do so.

The first is in force. Since 18 March 2023, every supplier to the Luxembourg public sector must issue invoices in structured form, with no size or value threshold. The framework comes from the law of 16 May 2019 transposing Directive 2014/55/EU, then from the law of 13 December 2021 which made issuance mandatory. The format is the European standard EN 16931, carried over the Peppol network. A PDF sent by email does not satisfy the obligation for those flows.

The second is not in force. A draft bill extending e-invoicing to transactions between businesses established in Luxembourg was approved by the Council of Government on 17 July 2026. It has not been voted. The published calendar remains indicative and forward-looking: reception capability expected on 1 January 2028, mandatory issuance for large and medium-sized businesses targeted for 1 July 2028, then extension to remaining businesses envisaged for 1 January 2029. The announced model reuses the same decentralised Peppol network, with no central clearance platform and no real-time reporting to the tax authority.

The consequence for a software decision taken today is clear. A choice made in 2026 commits a five to seven year cycle that will cross that horizon. Selecting a tool unable to connect to Peppol amounts to scheduling a second migration, with a data take-on, at the exact moment every business in the country will be calling the same integrators. The criterion costs nothing to set now and a great deal to retrofit later.

Which tool for which profile?

For a self-employed professional, the issue is discipline rather than power. A simple bookkeeping tool, connected to the bank account, able to output a PCN trial balance and a FAIA, is more than enough. The real cost line is not the licence, it is the time spent filing documents. Our recommendations for this profile are set out on the self-employed accounting page.

For a commercial SME, the dominant variable is document volume and the number of distinct VAT flows. This is the profile where bank integration, fixed-asset management and invoice recognition produce a measurable return. It is also the profile most exposed to a FAIA request, because the entry count makes any manual reconstruction impractical.

For a holding company or a SOPARFI with no operating activity, the reasoning inverts. Volume is low, but the requirements on presentation, on substantiating participations and on consistency with the tax return are high. Paying for a heavy suite makes no sense; conversely, a tool unable to produce a correct set of notes costs far more at closing.

For a fiduciary or an accounting firm, the question is no longer bookkeeping but series production: multi-file management, access rights, chart of accounts templates, bulk consistency checks and deadline tracking. The trade-off is the cost per file produced, not the unit licence price.

For a subsidiary of a foreign group, the breaking point is the dual constraint: serving the head-office framework while producing a local set compliant with the standard chart of accounts. Two architectures exist, local bookkeeping with a mapped upload, or group bookkeeping with a conversion layer. The first is more robust under audit, the second faster in consolidation.

Changing software without breaking the history

An accounting migration rarely fails on technique. It fails on opening balances, on duplicated counterparties and on unlocked periods. The rule we apply is never to switch mid-year when the calendar allows: migrating at the start of a financial year removes the question of which period an entry belongs to and makes the first closing comparable.

History is not migrated in full, and there is no point trying. You take on substantiated opening balances, the chart of accounts, active counterparties and fixed assets with their depreciation schedules. The detail of earlier entries stays consultable in the old system, for which read access and a frozen FAIA extract must be kept for each financial year concerned. It is that extract, not the old software, that protects you if an audit reaches back before the migration.

The retention period governs the rest. Books and accounting records are kept for ten years in Luxembourg, which means a migration decided today still leaves several financial years under the old tool. Terminating a licence without having secured the extracts means giving up your own defence.

Financial Services Accountant Luxembourg S.à r.l.-S operates as an accountant in Luxembourg. The firm holds two business permits issued by the Luxembourg Ministry of the Economy: no. 10077274/0 for the activity of accountant, and no. 10077274/2 for activities ancillary to the profession of chartered accountant within the meaning of article 1 of the amended law of 10 June 1999. For anti-money-laundering and counter-terrorist-financing purposes, accounting professionals other than chartered accountants fall under the supervision of the AED. These permits do not confer the title of chartered accountant or statutory auditor. We test tools on your data, run the migration and take on the bookkeeping if you would rather not operate a licence in house.