Extract Luxembourg Invoices to Excel for Bookkeeping

To extract Luxembourg invoices to Excel for bookkeeping, you capture two sets of fields in every row. First, the source-traceability fields that let you find the original document again: source file, page, document type, and a credit-note flag. Second, the Luxembourg VAT review fields: supplier VAT number, RCS number, invoice number, issue date, the taxable base and VAT amount split by rate, and the total including VAT. Luxembourg uses four VAT rates, so the per-rate split matters: 17% standard, 14% intermediate, 8% reduced, and 3% super-reduced. Invoices under EUR 100 can be issued as simplified invoices with fewer mandatory fields, which changes what you can expect to find in a row.

That field list is the whole job. The reason it stays a manual extraction job at all is that the documents arrive as PDFs rather than as structured data you could import directly. Luxembourg has no mandatory B2B e-invoicing requirement: in business-to-business transactions e-invoices are permitted but require the buyer's consent to receive, and no national CIUS has been implemented on top of its Peppol BIS Billing 3.0 standard, according to the European Commission's eInvoicing overview for Luxembourg. In practice that means your suppliers keep sending PDFs, scans, and the occasional photo of a receipt, and someone has to turn that pile into a spreadsheet.

Search for help with that and you land between two groups of pages that never quite meet. On one side are country-agnostic invoice-to-Excel converters that will read a PDF but know nothing about RCS numbers, business-permit references, reverse-charge wording, or the EUR 100 simplified-invoice line. On the other are Luxembourg compliance guides that explain in detail what a compliant invoice must contain, then stop well short of a spreadsheet schema or a workflow for documents you have received. This article sits in the gap between them: a column layout, an extraction prompt, and a review checklist built for received Luxembourg invoices, credit notes, and receipts.

The Column Schema for a Luxembourg Bookkeeping Spreadsheet

A good Luxembourg bookkeeping invoice spreadsheet does two things at once: it holds the numbers your accountant needs, and it lets anyone trace a row back to the document it came from. Build the layout in three groups, source-traceability columns first, then the invoice identity, then the Luxembourg VAT review fields. The table below is the schema, with a short reason each column earns its place.

Column	Why it earns a column
Source file	The filename the row was extracted from, so a queried figure can be checked against the original.
Page	The page within that file; multi-invoice PDFs and long line-item runs make this essential.
Document type	Invoice, credit note, or receipt; drives how the row is read and posted.
Credit-note flag	A simple yes/no so reversals are obvious at a glance and can be summed separately.
Supplier name	The party that issued the document.
Customer name	The recipient, useful when one workbook covers several entities or clients.
Invoice number	The supplier's reference, your primary key for matching and dispute.
Original-invoice reference	The invoice a credit note or correction relates to, so reversals tie back to what they adjust.
Issue date	When the invoice was drawn up.
Supply date	When goods or services were supplied; it can differ from the issue date and affects the VAT period.
Payment terms	The agreed terms, for cash-flow and due-date checks.
Due date	When payment falls due.
Supplier VAT number	The Luxembourg (or other EU) VAT identifier; its presence is the first VAT review check.
RCS Luxembourg number	The Trade and Companies Register reference, often shown as the supplier's RCS wording.
Business-permit number	Captured where present; some Luxembourg suppliers show it and it is worth recording.
Reverse-charge wording	Any text indicating the customer accounts for the VAT, which changes how the row is posted.
Simplified-invoice indicator	Whether the document is a simplified invoice rather than a full VAT invoice.
Taxable base by rate	The net amount for each rate present, in its own column per rate.
VAT amount by rate	The VAT charged at each rate, again split per rate.
Total including VAT	The document's gross total, used to reconcile against the base-plus-VAT figures.
Reason for non-taxation	The stated reason where no VAT is charged, captured where present.

The per-rate split is the part generic layouts get wrong. A single Luxembourg invoice can mix the 17, 14, 8, and 3 percent rates on different lines, so one combined tax cell loses the detail your VAT review depends on. Give the taxable base and the VAT amount their own column for each rate that appears, and the total-including-VAT column becomes a clean reconciliation target: the bases plus the VAT amounts should equal it.

This schema is built for documents you have received, not for issuing your own. If you need the rules on what fields a supplier's document should carry in the first place, that is a separate question, covered in what a compliant Luxembourg VAT invoice must contain. The columns above assume the invoice already exists and your job is to get it into a usable file.

The Extraction Prompt That Builds the Spreadsheet

Once you know the columns you want, the work is describing them. With a prompt-based extraction tool, the description of the schema is the configuration; there are no templates to build or rules engines to wire up. You write what you want in plain language and the columns come back in that shape. Here is a prompt that produces the Luxembourg layout from the previous section:

I'm preparing received Luxembourg supplier documents for bookkeeping and VAT review. One row per document.

Extract: Source File, Page, Document Type (classify as Invoice, Credit Note, or Receipt), Supplier Name, Customer Name, Invoice Number, Original Invoice Reference (for credit notes and corrections), Issue Date (YYYY-MM-DD), Supply Date (YYYY-MM-DD), Payment Terms, Due Date, Supplier VAT Number, RCS Number, Business Permit Number, Reverse Charge Wording, Simplified Invoice (Yes/No), Reason for Non-Taxation, Total Including VAT.

For VAT, create a Taxable Base and a VAT Amount column for each rate present (17%, 14%, 8%, 3%). For credit notes, show amounts as negative. If a field is not present, leave it blank rather than guessing.

That is a goal-oriented prompt: it states the purpose first, then the fields. Stating the purpose helps the extraction handle the edge cases a bare field list would miss, such as a credit note that needs its amounts flipped negative or a simplified receipt that is missing half the VAT detail. You can tighten it further, naming exact column headers or adding rules, or loosen it and let the field list carry the work. The same prompt drives the whole batch, which is what makes this repeatable across a month's worth of documents rather than a one-off conversion.

The output is a structured file in whichever format your downstream process wants: Excel to work in directly, or a Luxembourg invoice PDF to CSV path when you are loading into bookkeeping software that prefers a flat import. If you want the broader mechanics behind this rather than the Luxembourg specifics, the general process for converting PDF invoices to Excel walks through it. The Luxembourg version is the same process with the schema above as the target.

This is also where a purpose-built tool earns its place over manual entry. Invoice Data Extraction takes the same single prompt and applies it across a batch of mixed Luxembourg documents, up to 6,000 files in one job, including native PDFs, scans, and phone photos of receipts, and returns one consistent Excel, CSV, or JSON file. Every row it produces carries the source-file and page reference, so the source-traceability columns the schema opens with are populated automatically rather than typed by hand. When you are ready to turn a folder of received PDFs into that working file, you can extract invoice data to Excel automatically and adjust the prompt until the columns match how your accountant wants the file.

---

Handling Credit Notes, Corrections, and Receipts

A real batch is not just clean invoices. Credit notes, corrected documents, and receipts each behave differently in the file, and getting them into Excel without distorting the VAT figures takes a few rules. This is where getting Luxembourg credit notes and receipts to Excel correctly separates a usable working file from one your accountant has to unpick.

For a credit note, three columns carry the work: the original-invoice reference it relates to, the credit-note amount in the total, and the VAT it reverses in the per-rate columns. Show the amounts as negative and set the document-type and credit-note flag from the schema accordingly. Done that way, the credit note nets against the invoice it corrects when you sum a supplier's rows, and the per-rate VAT columns reverse the right amount of tax rather than leaving a phantom liability in the file.

A corrected invoice follows the same logic. Tie it back to the document it replaces through the original-invoice reference so it does not sit in the file as an orphan row that looks like a second, separate charge. The reference column is what keeps a correction connected to its original.

Receipts need a lighter touch. A till receipt or simplified receipt often is not a full VAT invoice, so it will be missing fields the schema expects, sometimes the supplier VAT number, sometimes the per-rate split. Capture what is actually on the document and set the document type to receipt rather than forcing it into the shape of a full invoice. That keeps the row honest and lets you treat receipts separately when it matters.

One distinction is worth flagging now and settling later. A normal credit note you have received from a supplier belongs in this workbook like any other document. A document tied to the submitted public-sector e-invoice path is a different animal and does not belong in the same bucket; the final section draws that boundary.

Review Checks Before the File Reaches Your Accountant

Extraction gives you the data; a short review turns it into a file someone can post from. Run these checks against the extracted rows before the workbook goes anywhere:

• Missing supplier VAT number. A blank VAT number on a document that should be a full invoice is the first thing to question, since it affects deductibility and may mean the document is a receipt rather than an invoice.
• Missing RCS or business-permit context. Luxembourg suppliers usually show an RCS number; its absence is worth a flag, even if it does not always indicate a problem.
• Totals that do not reconcile. For each row, the taxable bases plus the VAT amounts should equal the total including VAT. A row that does not add up points to a misread figure or a rate that was split incorrectly.
• Mixed VAT rates on one invoice. An invoice touching more than one of the 17, 14, 8, and 3 percent rates is normal in Luxembourg, but confirm each rate landed in its own column rather than being merged.
• Amounts under the EUR 100 threshold. Below EUR 100 a document may be a simplified invoice with fewer mandatory fields, so missing detail there is expected rather than an error; mark it so it is not chased unnecessarily.
• Reverse-charge wording. Where the document carries reverse-charge text, the customer accounts for the VAT; flag these so they are posted correctly rather than as standard-rated supplies.
• Receipts among the invoices. Confirm documents flagged as receipts are not being treated as full VAT invoices in the totals.

The reason to run this while the documents are fresh, rather than at quarter-end, is that questions are easier to resolve close to receipt. That timing also matters for Luxembourg's accepted-invoice principle for reviewing received invoices, which is worth understanding before you post anything you have not checked.

Keeping a Multilingual Supplier File Usable in English

Luxembourg's supplier paperwork rarely arrives in one language. A single batch can hold invoices in French, German, Dutch, and English, sometimes more, which is normal for a cross-border operation but awkward for a single working file. The fix is to separate what should stay in the source language from what should be standardized.

Preserve the original wording where the source text is the record: line-item descriptions, the supplier's legal entity name, and anything you might need to match back to the document during a query. Translating those into English can quietly change the meaning or break the link to the original, so keep them as they appear.

Standardize everything that is structural. Column headers, the document-type values, and any review status you add belong in English so whoever does the books can read the file regardless of which language each underlying document used. A row sourced from a German invoice and a row sourced from a French one should look identical in the workbook apart from the preserved description text.

The schema and the prompt do not change across languages. The columns are defined by what you want, not by the language of the source, so the same extraction produces the same layout whether a document is French or Dutch. The same approach applies more broadly to handling multi-language and multi-currency supplier invoices, where preserving source detail while normalizing structure is the consistent principle.

---

Where the Extraction Workflow Ends and E-Invoicing Begins

It helps to be precise about what this workflow produces and what it does not. The extraction turns received documents into a structured Excel, CSV, or JSON file for bookkeeping and VAT review. That is the full extent of it. Invoice Data Extraction reads the documents and exports the data in those formats; it does not file VAT returns, submit invoices to any authority, decide whether a given VAT charge is deductible, or stand in for your accountant's review. The file it gives you is an input to those tasks, not a replacement for them.

The boundary that catches people is the difference between extracting a received document and submitting a compliant e-invoice. Pulling a supplier's PDF into a spreadsheet is a reading task on a document you already hold. Submitting a public-sector invoice is a structured transmission with its own format and channel, explained in Luxembourg public-sector e-invoicing through Peppol and MyGuichet. If you are issuing an invoice to a Luxembourg public-sector body, that is the path to follow, and no amount of spreadsheet extraction substitutes for it. The workflow in this article is for the documents coming the other way: the invoices, credit notes, and receipts that land in your inbox and need to become a clean, reviewable file.