Accounting data export: clean files at every month-end close

In the first days of the month, what travels between the company and its external accountant is archives of PDFs, Excel sheets redone three times and messages along the lines of “the haulage invoice is still missing”. The solution has a dry name, accounting data export, and a simple purpose: it cuts this exchange down to one file that the accountant’s software reads directly and a short list of things left to clear up.

The hard part is not the file itself but what it contains. If the data goes out with duplicates, missing documents and wrong tax identification codes, the accountant receives the same problems, only in a more elegant format.

Accounting data export: the accountant’s software dictates the format

The first question is not for you but for your accountant: what software do they use and what can it import? Many accounting packages accept imports from files with a fixed structure (CSV tables, XML or proprietary formats), described in their documentation. That is where we find out which columns are mandatory and how business partners and items are identified.

Then comes the mapping, that is, the table of correspondences between what your software calls things and how accounting wants them: product categories against accounts, VAT rates, document types, cost centres. The accountant fills it in and adjusts it when something new comes up. A product with no mapping does not go out with a guessed value; it stops the check.

• Sales: invoices issued, reversal invoices, delivery notes, with lines and rates.
• Purchases: invoices received and goods receipts, linked to each other.
• Incoming and outgoing payments: through the bank and in cash, allocated to documents.
• Master data: business partners and items that are new or changed in the period.

What is checked before the file goes out

The checks are simple rules, run over the whole period, each with a result that a non-programmer can understand too. Some stop the export, others only warn; the accountant decides which is which.

Every problem found comes with a direct link to the document concerned, so that the person who entered it can correct it quickly. After the corrections, the check is run again.

• Missing documents: gaps in invoice numbering, goods receipts without an invoice, invoices without a goods receipt.
• Duplicates: the same supplier and the same document number entered twice.
• Tax identification codes: a missing code, or a code that fails check digit validation.
• Totals: the sum of the lines differing from the document total, VAT that does not correspond to the rate.
• Unallocated payments: amounts that have come into the bank and are not linked to any invoice.

The month-end checklist, step by step

The close is not a moment; it is a series of steps taken by different people. We put them in a list that is regenerated automatically every month, with an owner and a status on every line. Say you have a warehouse, an online store and two sales reps: the storekeeper confirms the goods receipts, sales confirms that all deliveries have been invoiced, and the reps hand in their expense claims.

Some of the steps tick themselves off, based on the data: bank statements have been imported up to the last day, the checks show no more errors. The others are confirmed by a person. When the list is complete, the file is generated and sent to the accountant.

After handover, the period is closed in your software: its documents can no longer be changed without an explicit, logged reopening. Otherwise your data and the accountant’s end up no longer matching.

What remains the accountant’s responsibility

The export does not do the accounting. The entries, the closings and the filings, including the SAF-T file, are prepared by the accountant, in their own software. Who files them and who is responsible for them is a matter for your agreement with the accountant and the rules of the profession, not for software. Our role stops at data that is complete, consistent and in a form the accountant can take in without retyping.

Sometimes reporting requires information that your software does not hold at all or holds mixed in with other data, for instance a standard code for the unit of measure. The accountant tells you what is missing; we add the fields and make them mandatory at data entry.

If your invoicing software and the accountant’s are both well-known products, check first whether a connection between them already exists, offered by one of the vendors.

From the first test file to a monthly routine

We work on a month that has already been closed, for which the accountant has their own results. We generate the file, the accountant imports it into a test copy of their software, and we compare the totals: sales, purchases, VAT, partner balances. Differences point either to a wrong mapping rule or to an old problem in the data.

We usually write the export as a module of the existing software or as a separate service, in Laravel or Python, which reads your software’s database without changing it. If both programs have an API (a route by which they send each other data directly), the information can flow without files as well. We keep every file sent, with the date and the results of the checks.

This is a typical project description: it shows how we usually approach this kind of work and does not present a project carried out for a particular client. Every real project starts from your company’s situation, and the stages, timescales and price are agreed after the initial discussion.