...
Table of Contents |
---|
...
Overview of the Reconciliations
The view of the [Reconciliations] dialogue is based on the settings made in the master data, only those reconciliations that were activated in the master data for the respective company are visible. The following information is presented in the table:
...
Tip | ||
---|---|---|
| ||
If a report is imported in the [Import] dialogue after the reconciliation has been carried out, the reconciliation results are reset. |
Detailed view of the Reconciliations
In the detailed views of the reconciliations, there is a list of reconciliation items according to different columns for each reconciliation. A reconciliation result and a status are stored in each reconciliation table.
...
The other columns of the voting tables depend on the respective reconciliation and are explained in detail in the corresponding reconciliation.
Reconciliation 1: Plausibility of VAT amounts in the VAT report
Reconciliation 1 checks whether the VAT in the tax report [RFUMSV00] matches the amount resulting from the multiplication of the stated tax base with the VAT rate of the tax code (saved in the Master Data). Possible inconsistencies are usually rounding differences.
...
Check | Values from the RFUMSV00 | Calculation in VAT@GTC | Difference | Limit for automatic adjustments | Automatic adjustments of the | Result |
---|---|---|---|---|---|---|
Tax base | 189 € | 1.000 € x 19 % = | 1€ | 5€ | tax | The deviation is below the limit for automatic adjustments. At the time of import, the tax is corrected by 1€ and added to the declaration. In the columns [Calculated Tax base / Tax] this automatic adjustment is already taken into account. The column [Initital difference Tax base / Tax] still shows a difference. In the column Reconciliation Result an exclamation mark and no tick is deposited. Editing is not necessary as this was done automatically. |
Assessment base | 1.000 € | 185 € / 0,19 = 994,73€ | 5,27€ | 5€ | tax base | The deviation is above the limit for automatic adjustments and therefore has an error. Therefore, no automatic adjustment is made, requiring manual intervention. The reconciliation status is represented by an X. Editing of the reconciliation position is initiated via the checkbox in the [Edit] column. |
...
All changes made can also be viewed by calling up the change log.
Reconciliation 2: Comparison of G/L account with VAT return
This reconciliation requires a separate G/L account for VAT to pay or recover. The amount to pay or recover calculated in the VAT return is compared to the balance of the account for VAT to pay or recover from the RFBILA, which has been imported for the current month.
...
If the reconciliation is on status [green], there is no longer a note in the resubmission of the current period (prerequisite for this: no open items from the previous months).
Reconciliation 3: Differences between VAT reports V00 and V10
Reconciliation 3 compares the amounts of the tax base from the reports RFUMSV00 and RFUMSV10 (monthly/quarterly VAT return (preliminary VAT return) and additional list) per tax code. Differences are displayed in an overview table.
...
The adjustment of RFUMSV00 to RFUMSV10 is not the rule. However, if the RFUMSV00 is to be adjusted to the RFUMSV10 anyway, the tax code to be adjusted is already defined by the reconciliation position. Only the correction value and a comment must be specified. This value is entered in the declaration in the field(s) to which the tax code concerned is mapped.
Reconciliations 4-6: Completeness check of revenue, expense and balance sheet accounts
Challenge: Sign changing
The VAT@GTC follows certain rules regarding the signs during the standard report import. In the reconciliations 4, 5 and 6, the values from the RFUMSV10 are compared with those from the RFBILA. This results in the following challenge:
...
- Value RFBILA is bigger than value RFUMSV10 This is an indication of existing bookings without tax code. If the value from RFUMSV10 is 0, this may be related to a non-tax-relevant account (especially in the reconciliation 6).
- Value RFUMSV10 is bigger than value RFBILA This is an indication of a faulty correction booking.
Tip | ||
---|---|---|
| ||
There is an option via a flag to hide all accounts in reconciliation 4-6 that do not appear in RFUMSV10. This usually concerns accounts that are In the area of reconciliations (master data), the option to hide zero values from the reports can be switched on and off for reconciliations 4 to 6. By switching on the option, the result of the respective voting is slimmed down so that rows without values are no longer displayed. This usually concerns accounts that are not relevant for VAT and that are never posted to with tax codes. |
...
Tip | ||
---|---|---|
| ||
If any findings appear during the first months of the project, these can be set to [not VAT report relevant] in the VAT@GTC. Generate an Excel document with the findings (can be done directly in the Reconciliation dialogue) and discuss it with the accounting department. In addition, it can be decided at a later point whether the not VAT-relevant accounts can be deleted from the master data area of the VAT@GTC. Thus, these are no longer taken into account in the reconciliations. |
Reconciliation 7-8: Plausibility check input and output tax code
Bookings with certain tax codes and thus types of tax code (VAT and input tax) are usually posted to the same account groups.
Accounts of the profit and loss account are important here, they are checked by reconciliations 7 and 8. The RFUMSV10 serves as the source.
...
- In the reconciliation table, the checkmark for editing the position can be ticked.
- Then an entry opens under the reconciliation table, under which the position can be edited. First the account and the difference amount are displayed. In the line below, the position can be reassigned. The correct tax code for this entry must be selected there. The adjustment value and a comment are also required. If this adjustment is saved, 2 adjustments are automatically entered in the declaration. On the one hand, the value on the original, incorrect tax code and the associated fields are counter-posted in the declaration. On the other hand, the value is entered on the correct tax code and the associated fields.
- The corresponding document in the ERP system should be corrected. It should be remembered here that this is usually a posting in the subsequent period. For this reason, resubmissions are created in VAT@GTC for the adjustments so that the adjustments can be eliminated again in the corresponding later period.
Reconciliation 9: Reconciliation with ESL
Functionality
The aim of the reconciliation 9 is to identify whether the reported values in the ESL match to the values in the monthly VAT return. In order to perform this reconciliation in the VAT@GTC the amounts reported in the ESL are needed.
The values from the VAT return are included in the reconciliation on the basis of the relevant fields. Based on the form field allocation, the VAT@GTC differentiates between intra-Community supplies (field 41), as well as supplies of agricultural and forestry businesses according to § 24 UStG to customers with a VAT ID number (field 77), non-taxable other services (field 21) and intra-Community triangular transactions (field 42). The values from the ESL are added up per type.
Type of transaction | ||
---|---|---|
Intra-Comunity Supplies | Field 41 + Field 77 | All Entries with type of transaction "0" - Supplies- summed up |
Intra-Comunity Services | Field 21 | All Entries with type of transaction "1" - Services - summed up |
Intra-Comunity triangulations | Field 42 | All Entries with type of transaction "2" - triangulations - summed up |
In the master data, you can set whether the reconciliation is to be carried out when the advance return for VAT is created or when the recapitulative statement is created, or in both declarations.
...
Reconciliation
...
Reconciliation difference
This reconciliation usually results in differences, since, in contrast to the monthly VAT return, the amounts in the ESL do not contain cents (the amounts are displayed in euros when importing the RFASLM). Thus, in large ESLs the differences cam amount to more than € 100. The user can set a tolerance limit in the master data (optionally with absolute amount or percentage). If the deviation is within this tolerance limit, the reconciliation is no longer faulty, but is displayed with a yellow exclamation mark.
In the event that an error is detected in the reconciliation that is relevant for one of the two declarations, this must be adjusted manually. The reconciliation can then be carried out again.
Reconciliation 10: Deviation from the mean of the last 12 months
Tip | ||
---|---|---|
| ||
The reconciliation 10 only makes sense for a company with the constant fiscal year. |
...
The configuration is possible in the [Master data] area under [Reconciliations]. To check the requested field, a tolerance limit hast to be specified. Either an absolute or a percentage tolerance limit can be specified. If both variants of the tolerance limit are configured for a reconciliation position, the percentage tolerance limit applies.
For a more detailed analysis, the 12-month comparison with mean deviation report should be used.
Reconciliation 12Reconciliation 12-13: Plausibility check
Tip | ||
---|---|---|
| ||
These reconciliations make sense only if the company has a right to full VAT deduction. |
...
If certain tolerance limits are not exceeded in these two reconciliations, the user has the choice to ignore the difference or take this resubmission into the next period, where it can be checked again.
Option to hide zero values in RFUMSV10 and RFBILA
...
Reconciliation 14 Zero balance validation of G/L accounts
Reconciliation 14 checks whether there is a zero balance on deposited G/L accounts.
The zero balances are set in the area Master data → Reconciliations → Manage reconciliation accounts (edit).
Each account must be individually marked as to whether it belongs to the group zero balance G/L account and is to be taken into account in reconciliation 14.
When performing the reconciliation, it can be stored that the facts have been checked and that there is no error.