Hosting Accounting Exports: Handing Your Books to Your Accountant
"Export the invoices" is at least three different operations with three different shapes. What breaks in the handover, and why you should do it in March rather than January.
"Export the invoices" is at least three different operations with three different shapes. What breaks in the handover, and why you should do it in March rather than January.
Your billing platform is not your accounting system, and the handover between them is where a lot of hosting businesses lose a weekend every month. The platform knows what you invoiced. The accountant needs it in a form their software will accept, with the VAT broken out the way their jurisdiction expects, and reconciling to what actually landed in the bank.
Here is what that handover involves, what breaks, and what to check before you assume your platform can do it.
Not accounting or tax advice. Reporting obligations, accepted file formats and VAT treatment vary by country and by the software your accountant runs. Confirm the specifics with them before relying on any of this.
People say "export the invoices" as if it is one operation. It is at least three, and they need different shapes.
The accounting handover. Every sales document for a period — invoices, credit notes, and the VAT on each — in a format the accountant's software imports. This is a machine-readable file, and it is the one with the most constraints.
The reconciliation. What was actually paid, when, through which gateway, against which document. This is what ties your invoices to your bank statements, and it is a different data set: an invoice is not a payment, a partial payment is not a full one, and a refund is a negative that has to appear.
The archive. The documents themselves, as issued, as PDFs. Some jurisdictions require you to retain the document as sent, not just the data behind it. A regenerated PDF from a template that has since changed is not the same artefact.
A platform that does the first and not the other two leaves you assembling the rest by hand.
CSV. Universal, imports into everything, and carries no structure. Fine when your accountant maps the columns once and you never change them. The failure modes are all encoding and locale: decimal commas against decimal points, date formats that flip day and month, and UTF-8 characters in customer names that arrive as mojibake in a spreadsheet opened with the wrong settings.
XLSX. A real spreadsheet with typed cells, so numbers arrive as numbers and dates as dates. Better than CSV for a human reviewer and for anything that will be read before it is imported.
Country-specific XML. Several jurisdictions have an accounting or fiscal XML that local software expects. These are strict — a missing field or an unexpected element and the import fails outright rather than partially. The important caveat is that these formats are usually vendor- or authority-specific: an XML built for one accounting package is not generic interchange, and it will typically only be accepted by that package. Do not assume an XML export is portable.
PDF, in bulk. For the archive, and for the accountant who wants to see the document rather than the row.
VAT allocation across mixed supplies. A single invoice can contain a standard-rated service, a reverse-charge line to a VAT-registered business in another member state, and a zero-rated item. Exporting a per-invoice total loses that. The export has to break VAT out per rate per document, or your accountant does it by hand.
Cross-border rules. B2B inside the EU with a valid VAT number is generally reverse charge; B2C is generally your rate or the customer's depending on the supply and the thresholds; outside the EU is different again. The export needs the customer's country and VAT status attached to the line, not just the amount.
Credit notes exported as negative invoices. They are a distinct document type with their own sequence and their own reference to the original. Flattening them into negative invoice rows is how a set of books stops matching the documents you actually issued. Covered in credit notes, refunds and clawbacks.
Proformas leaking into the export. A proforma is not a tax document. If it appears in the accounting file it inflates your declared turnover. See invoice numbering and sequence.
Multi-currency. Your accountant needs the amount in your reporting currency at a defensible rate for a defensible date. If the export only carries the transaction currency, someone is converting by hand, and the rate they pick will not be the one you used.
Partial payments. An invoice half paid by account credit and half by card has to reconcile to two movements, not one. If your export shows only the invoice total, the bank reconciliation will not close.
The last one is the most commonly missing, and it is the one your bank reconciliation depends on.
FluxBilling exports accounting documents in four formats from one place: XLSX workbook, generic CSV, SAGA XML, and bulk PDF for the archive. Invoices, proformas and credit notes are distinct document types throughout, so credit notes export as credit notes rather than as negative invoices, and proformas stay out of the tax document set. EU VAT allocation is computed in the export, with per-rate breakdown and the customer's country handled by the exporter rather than left to the reader.
Two honest caveats. The SAGA XML format is for that specific accounting package and should not be treated as generic interchange — if your accountant uses something else, the XLSX or CSV path is the one to use, mapped once. And if you invoice from more than one legal entity, talk to us about the setup before assuming the export separates them the way your accountant needs.
See billing features and current pricing.
Do the handover once, early, with a real month of data and your actual accountant — not at year end with twelve months and a deadline. The mapping problems, the VAT edge cases and the missing payments export all surface in the first ten minutes of a real import, and every one of them is cheap to fix in March and expensive in January.
You will not run out of IPv6, which is exactly why its allocation goes undocumented. Meanwhile IPv4 leaks onto dead services. Both are billing problems, not just network ones.
A customer upgrades on day twelve of a thirty-day cycle. What they owe, when, and what the next invoice says differs by platform — and sometimes by which screen you used.
The payment succeeded, the provisioning failed, and the invoice says paid. It is unavoidable — the question is whether your platform notices, or the customer does first.