Data export tax audit

GoBD: Principles for the proper keeping and storage of books, records and documents in electronic form and for data access

About Turnover/Data export tax audit you can access the data export audit. The files output here are saved in CVS format and can be read in by the tax office. Please note which account area you are in. If you want to output the data from a cash account area, such as SALES, please change the corresponding account area before the GoBD export.

You can find out how to change the account area here </ignore>Kontenbereich select

If you require export data from an archive area, please switch to the relevant archive area first.

If you select the menu item Data export audit menu item, the following window opens Data export audit:

You can now make the desired settings:

The period to be exported is defined under point (1).

Point (2) Here you have the option of choosing between two invoice PDF exports.

• Invoices sent by e-mail. Only the invoices actually sent by e-mail are exported.

or

• All invoicesAll invoices written in the period defined above are exported as a PDF file.

In point (3) you define an output directory to which the CVS files are to be exported.

If you want to encrypt the files with a password when opening them, enter an appropriate password at point (4). This may then be required later when opening the export files.

Then click on Export Point (5)

PC CADDIE asks once again whether the fiscal export should be started for the selected account area.

Confirm with Export

Once the export has been completed, you will be shown some more information about the fiscal export. These are the account range exported, the period, date and time of the export, the name of the computer, the Windows user, the PC CADDIE user and the output directory.

Confirm with OK. The file explorer (Windows Explorer) then opens with the selected link (1) and a ZIP folder (2). You can already recognise the exported account area and time period in the name of the ZIP folder. You can open the ZIP folder by double-clicking on it.

This ZIP folder contains another subfolder with the name of the account area. You can also open this folder by double-clicking on it. It contains the CVS files, which you can open with your standard spreadsheet programme.

The export files then look like this:

If you have assigned a password and want to open one of the above-mentioned files, you will receive the following message. Here you must then enter the password previously entered in PC CADDIE and, after entering the password, confirm with OK after entering the password.

The contents of the individual files are listed below:

Articles used in the defined period of the exported account range

Product groups used in the defined period of the exported account range

All bookings from the selected account area are listed.

The fields that are important for economic analyses are marked in bold.

Please filter out the lines with KONTTYP „a“ and „p“ for addition via KONTBRUTTO, as these are not relevant to turnover. The total sum of all postings should normally be 0, as sales postings and payment postings cancel each other out in terms of amount. You can therefore obtain the turnover by filtering out the lines with KONTTYP „Z“. If you only filter on ACCOUNT TYPE „Z“, you will receive the payments.

Detailed information on cash bookings is output. Similar to the cash log </ignore>Kassenprotokoll

The cash log was introduced at the beginning of 2016.

It was activated automatically for customers as soon as the necessary update was installed.

Bookings prior to activation are not logged retrospectively and are therefore not output.

Cash book entries

All changes are logged in this file.

• Article changes
• User changes (new, change, delete)
• Confirm cash balance
• Deactivate GoDB-compliant cash book
• Daily closing
• Undo multiple invoices
• Cancel invoice
• Change invoice number

Customers used in the defined period of the exported account range

Information on fiscal export

• Issued account range
• Period of the postings / invoices
• Date and time of the export
• Computer name
• Windows user
• PC CADDIE user
• Data path to the PC CADDIE main directory

Round drink consumed on the premises - VAT still 7%

The article „round drink“ has probably been created as an „out-of-home article“ with 7% VAT. Initially, this is probably also correct in terms of content, because such a round drink is usually a small PET bottle that the golfer takes with him on the round and does not drink in the catering establishment. (at least that's how I know it in practice, I can't say anything about the content of the specific case)

I suspect that in this case this bottle was to be opened in the restaurant and the cashier unknowingly used this item and increased the price to 3.80 for on-site consumption. In any case, the additional text „On the premises“ was entered manually as the reason for the price increase.

However, there is of course no technical connection with the VAT for such manual changes. - This is pure text, the cash register cannot judge the tax component in such a case and the employee was probably not aware of it either.

In particular redemption and top-ups of voucher cards.

► In principle, voucher items with an empty KONTRGNR can be omitted from the evaluation. In this case, these are documentation postings for the credit cards, which are generally used across all areas (i.e. also in golf operations, for example, for the purchase of practice balls). We have not checked how exactly this is handled by the specific customer - the customers are quite free in their organisation.

In any case, it may well be that credit from this card is used within the restaurant cash register, which was charged at the golf course cash register. Ultimately, these are transactions which, in my opinion, would result in a settlement between the restaurateur and the golf establishment without knowledge of the customer's specific organisation. Ultimately, however, we can only offer all possibilities to correctly map these transactions.

The two bookings you mentioned without a voucher number are purely transfers from one person to another - for example, if the man's credit card is used to pay his partner's bill. These postings are ultimately only informative for documentation purposes, but ultimately not part of the till receipt, which is only about paying for meals with card credit, for example, which is why these transfers do not have a receipt number. (They are cancelled out by the amount in KONTBRUTTO anyway).

KONTRGNR 2019009971: 22 data records, 2 of which with KONTTYP f

► Generally, bookings with KONTTYP „f“ are family transfers. These are usually used to document when, for example, food is transferred from the daughter to the father when he pays the bill for the children - hence the name.

Here you can see the specific entry in grey - technically there are two data records, the amount is booked out for one customer and booked in for the other - the process cancels itself out and ultimately plays no role from a pure cash turnover perspective:

In this case, a receipt for a total of EUR 135.30 with an amount of EUR 30.00 was paid by credit card, the remaining EUR 105.30 was paid in cash - actually a relatively normal transaction.

Presumably due to misunderstandings during service, a „family transfer“ in the figurative sense happened here by mistake: The turnover, which was originally posted to the standard „walk-in customer“ account without a specific customer, was transferred during the payment process to a customer called „voucher, voucher“ - in other words, obviously a clearing account.

KONTRGNR 2019011082: 214 data records in the Bookings file - 212 of which have the data record type (KONTTYP) „q“.

►In this case, it is the payment of a debt in the customer account using a credit card. It is possible to post receipts to an account „on account“ in the cash register. These postings then appear in the cash register accounts in this way - here in the example voucher 2019001207:

An OI account is then kept for these customers, in which these carryovers are summarised and from which some customers generate direct debits or monthly statements. In this specific case, the function to pay the debt from the open item account was used in the cash register - then all receipts with their details are collected together and the total balance to be paid is calculated - in this case EUR 35.57:

In that case, redeeming the voucher credit ultimately results in a credit to the OP account which settles the debt there and that's it. The individual data records with the identifier „*“ followed by „PER“, „INV“ or „DET“ (for person, invoice and detail) are only used for internal documentation of which items were affected by this process. These data records are also labelled with KONTTYP „q“. The actual transaction data records are, of course, already available elsewhere (you should also find them in the export in the appropriate places).

As these data records are only used for documentation purposes, the fields KONTBRUTTO and KONTNETTO are also 0 here. Overall, the cash register is programmed in such a way that KONTBRUTTO must contain the really decisive value.

KONTRGNR 2019018907 - orders and payments with different dates

► In our cash register solution, it was possible to leave existing orders in the cash register that were already entered („ordered“) in October, as you can see in the example here. They were then already permanently booked and could no longer be deleted (if necessary, they could only be cancelled by a documented offsetting entry). This simplified the usual payments in the club area, for example at the end of the month etc., although we actually recommend posting via the OP area in such cases, as shown under 4.

In this case, the period is also quite extreme: The customer only finally paid his two receipt items from October 2019 in May 2020.

As the export was limited to the transactions in 2019, the order postings are available in your export, but the document header, the order item from May 2020 and the payment of the total amount belong in the export for 2020.

KONTRGNR 2019007581 Treatment of vouchers

►In this case, as in point 4, it is again a matter of clearing a debt in the customer account using a credit card. A voucher is then generated with the order items, which is cleared by a transfer to the OP account. From the cash register perspective, it looks like this:

The bookings then appear in this form in the OP account (here of the restaurant):

Only the document totals are collected here and managed as a customer account.

In the case of the voucher in question 2019007581, the customer balance 106.78 was paid using the credit on the credit card. For this reason, the credit withdrawal from the credit card is also posted against this OP account so that it is ultimately balanced. There are no further details in this receipt - the link to the services paid for via the OP account has thus become very indirect. In individual cases, this can of course only be traced via the accounts in the software.

It is not possible to see where the voucher card was loaded in the transactions here, but there are analyses within the software for the individual credit card - depending on the constellation at the customer, it is conceivable that the loading is carried out in the golf operation independently of the catering operation and that the use of this credit in the restaurant leads to a settlement between the facility operation and the catering operation. (see also point 2.)

CONTRGNR 2019016690

► These are three transactions that took place in immediate succession. As Mr Axel Heck is part of our team, I assume that the voucher function was to be tested or demonstrated here.

1st voucher 2019016687 13:12: Sale of a voucher for EUR 100.00 and cash payment of the same.

2. 13:27 this voucher was cancelled, therefore a cancellation voucher 2019016690 was created, which cancels the actual sales transaction with the opposite sign. The voucher is therefore back in the cash register as an ordered product.

3. the voucher sale itself was then cancelled and offset in the cash register. This is now a 0 voucher, which was cancelled at 13:33 with voucher number 2019016691.

Ultimately, all postings in this context cancel each other out and merely document a completely cancelled voucher sales transaction.