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:
| Column | Contents |
|---|---|
| Reconciliation | All reconciliations configured for this company are listed here by name. |
| Status | Once the reconciliations are conducted, a status for that reconciliation is shown here. There are two possible outcomes:
|
| Number of Errors | This column shows the number of reconciliation items that were identified as incorrect by the reconciliation. |
| Advice | If the reconciliation is not configured as mandatory, the advice "Completion can be shifted" is displayed here first. This can be done via the action in the next column. As soon as this action has been carried out, the processing note is "To be completed later". However, if the reconciliation is configured as mandatory, the advice is "Completion cannot be shifted" and cannot be changed. |
| Action | The action in the column can change the advice. If the action [into next period] is performed, the processing note is changed to " To be completed later". This can be done if the error is to be considered later. The action [into previous period] reverses this operation and moves the processing of the reconciliation back to the current period. An action for reconciliation can only be performed in this column if it is not configured as mandatory. |
Good to know!
Click on [Run reconciliations] to start the process, the results will be displayed in the same dialogue.
Good to know!
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.
There are 3 different reconciliation results:
| |
Status |
|
| Depending on the reconciliation, there are one or two columns with which the editing of a reconciliation item can be started or carried out. If a check mark has been placed under [Edit] or [subject to reporting] for a reconciliation item, editing is always possible under the reconciliation table. By setting a check mark in the column [Not subject to reporting] or [Audited], the reconciliation item is directly set to Successful and the processing is completed. Praxishinweis In the change log of the reconciliation, a file attachment can be uploaded for each change. |
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.
Reconciliation table
In the reconciliation table, there are mainly columns that refer directly to RFUMSV00 and calculated columns:
| These fields are all filled directly from the import of the RFUMSV00 and thus mirror the RFUMSV00. |
| Calculated tax (base) | The calculated Tax base is determined from the tax rate and the tax value. The calculated tax value is determined from the tax rate and Tax base. Resubmissions and automatic reconciliation 1 adjustments are already included in these columns. This column is also updated for manual adjustments. |
| Initial difference base /tax | These columns show the difference between the Tax base (or tax) in RFUMSV00 and the Tax base (tax) calculated from RFUMSV00. In these columns only the RFUMSV00 is considered, no further changes in the VAT@GTC. Good to know Therefore, it is not necessarily true that [Assasment base from VAT return] - [Calculated Tax Base] = [Initial Difference Tax Base]. The [Calculated tax base] field is updated with each adjustment, the other two fields remain unchanged. The same applies to the corresponding tax fields. |
Functionality
The functionality of the reconciliation is explained below using examples. In the example we use a tax code with the tax rate 19%:
Example 1 (No error):
Check | Values from the RFUMSV00 | Calculation in VAT@GTC: | Difference | Result |
|---|---|---|---|---|
Tax base | 190 € | 1.000 € x 19 % = 190 € | 0€ | This reconciliation position is without error. |
| Assessment base | 1.000 € | 190 € / 0,19 = 1000 € | The status is marked with a tick and no editing is necessary. |
Example 2 (Error)
Check | Values from the RFUMSV00 | Calculation in VAT@GTC: | Difference | Result |
|---|---|---|---|---|
Tax base | 50 € | 1.000 € x 19 % = 190 € | 140€ | This reconciliation position has an error that requires manual intervention. |
| Assessment base | 1.000 € | 50 € / 0,19 = 263 € | 737€ | The reconciliation status is shown my X. Editing of the reconciliation position is initiated via the checkbox in the [Edit] column. |
For reconciliation 1, it is possible to configure a limit for automatic adjustments per company. For this, it must be configured system-wide whether the tax or the tax base is to be adjusted in the case of an automatic adjustment. The limit then refers to the side that is to be automatically adjusted.
Good to know
The configuration of a limit for Automatic Adjustments is done in the dialogue [Master Data → Reconciliations]. In the dialogue [Settings → Countries → Edit Country] it can be configured which side is automatically adjusted.
Example 3 (Limit for automatic adjustments)
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. |
Good to know
If resubmissions are activated, resubmissions are also created for automatic adjustments. The VAT_RECON1_RESUB_LIMIT flag can be activated to automatically set resubmissions from automatic adjustments to completed.
Handling of a reconciliation position
If a reconciliation position is considered incorrect, a corresponding manual change can be made via the [Edit] column.
After selecting the appropriate line, an edit box opens below the reconciliation table where either the assessment basis or the tax can be adjusted. In these cases, the user has to decide whether the assessment basis or the tax is to be decisive for the VAT return. For this purpose, a correction value and a comment with at least 5 characters must be created in the corresponding line. The change is completed via the [Save] button bar and transferred to the declaration. The comment is also displayed in the declaration to identify the change. If the deviation is reduced to 0€ with the manual change, then the reconciliation position is also considered completed.
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.
Reconciliation table
| These columns describe the G/L account for VAT to pay or recover that is compared with the calculated tax. |
| Amounts from RFBILA | This column shows the value posted to the account for VAT to pay or recover in this month. Manual changes to the account for VAT to pay or recover entered in VAT@GTC are included here. |
| Amounts from tax codes | This column shows the calculated tax value from the declaration. For this purpose, the value is taken directly from the field VAT advance payment/surplus in the declaration. |
| Difference | In this column, the difference between the calculated tax and the booked tax is drawn. If this value is higher than the tolerance limit configured for this reconciliation, reconciliation 2 is incorrect. |
The amounts often do not match in this reconciliation. Reasons for this can be:
- Account clearing of the account for VAT to pay or recover does not take place on a monthly basis.
- Remaining balances on the account
- Postponement of account clearing due to the permanent deadline extension
The aim of this reconciliation is primarily the procedural derivation of the difference. After reconciliation, the declaration or the account balance must be adjusted.
Change VAT Return
The change of the declaration is an absolute special case (reason: changes of tax codes or subsequent postings take place in reconciliation 1 as well as directly in the declaration form).
Important for the adjustment is the selection of the tax code in connection with the tax code type and the correct specification of the correction value (for each tax code type, please use exactly the amounts incl. sign as they are specified by the system).
However, it is recommended not to carry out the adjustment in this reconciliation. Alternatively, the following procedures should be considered:
- Change directly in the reporting form by adjusting the respective tax code in the corresponding field position there.
- Then carry out the reconciliation again - after that the status should be [successful].
Good to know
Only tax codes that have been mapped to a tax field can be changed.
Change RFBILA
Adjusting the relevant account for VAT to pay or recover from the balance sheet is the standard procedure in case of a reconciliation difference. The respective account is specified by VAT@GTC by default. It is important to use the correct sign for the adjustment. This is also specified by VAT@GTC by default. As described in the section [Reconciliation 1: Plausibility of tax amounts in the VAT report], it is important to be able to derive the difference procedurally. If this is not the case, the reconciliation should be deactivated for the company.
It is advisable to enter a meaningful comment in the comment field. In addition, attachments can be uploaded in the change log of the reconciliation.
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.
Possible reasons for differences are deliberate or incorrect settings in the SAP system or a modification of the standard report. Based on the cause of the differences, it must be decided to what extent the monthly/quarterly VAT return (preliminary VAT return) values have to be adjusted. In addition, it must be selected whether the tax base of the RFUMSV00 or the RFUMSV10 should be decisive for further reconciliations. Since matching the tax bases of both reports is important for the completeness and accuracy of the monthly/quarterly VAT return (preliminary VAT return), this reconciliation is also the basis for the reconciliations 4 to 8, where both reports are used. If the reconciliation 3 contains errors, the system will inform the user in the subsequent reconciliations.
Good to know!
It is recommended to collect the differences for the companies over the first few months, send the incorrect tax codes to the SAP department using the [Excel view] and search together for possible reasons.
Change V10
The adaptation of the RFUMSV10 to the RFUMSV00 represents the regular procedure.. This adjustment does not result in a change to the declaration, since the RFUMSV10 is not used to create the VAT return.
When adjusting the RFUMSV10, an account must be selected in the detail view next to the specified tax code. All accounts available in RFUMSV10 and posted in the balance sheet for tax purposes are available for selection. If the required account does not appear in the list or if no special account is to be created, select the default account [—].
Change V00
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:
- When importing the RFUMSV10, the existing amounts per account are adjusted based on the tax code (output tax: = reversal of the sign / input tax: the sign is left as it is).
- When importing the RFBILA, however, the amounts are adjusted based on the accounts (asset/expense account = the sign is left as it is, passive/income accounts = reversal of the sign).
Thus, the findings contain no errors. Here is an example to make it clear: Standard booking from accounting: Expense on liability
- As a rule, an input VAT tax code is expected here because it is a company’s purchase.
- Regarding the expense account, the logic is: The sign for expense accounts is not reversed (RFBILA) as well as the sign in the input tax (RFUMSV10).
- For the passive account, on the other hand, the sign is reversed (RFBILA) and the input tax is left as it is (RFUMSV10).
Content of the reconciliations
The reconciliations 4-6 compare the values of the account balance from the RFBILA of the respective account type with the corresponding totals from the RFUMSV10.
The reconciliations can result in the following deviations:
- 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.
Good to know!
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 not relevant for VAT and that are never posted to with tax codes.
When processing the reconciliations, it can be decided whether this is a VAT report relevant or not relevant deviation. If the deviation is not relevant, the finding is set to the status [green].
However, if the user decides that the error is relevant for the declaration, the value from RFUMSV10 must be adjusted. Since in reconciliation 4-6 the RFUMSV10 and RFUMSV00 are expected to match, this also results in a change of the RFUMSV00 and thus a change of the declaration.
The initial situation for such a change is that a posting was made in SAP without a tax code. Therefore, the tax code that should have been used for the entry must be specified when making the change. By mapping this tax code, the amount and the comment, both of which must then be entered, end up in the declaration.
Good to know!
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 reconciliation 7 all accounts booked in RFUMSV10 with input tax or ESE are checked with regard to incorrectly booked liability or revenue accounts.
In reconciliation 8 all accounts booked in RFUMSV10 with output tax or ESA are checked with regard to incorrectly booked activity or expense accounts.
Possible reasons for reconciliation failure:
- Account has been classified incorrectly in the master data area (delete and create new account)
- The amount was posted to an incorrect account. This has no effect on the declaration and can therefore be completed in VAT@GTC as not relevant for reporting.
- The finding is not an error (for example, a negative income was booked on the expense account and is therefore not relevant)
- The amount was posted to an incorrect tax code. With this type of error, the item must be actively processed.
If the amount was posted to an incorrect tax code, proceed as follows:
The amount must be recorded with the tax code. The editor must perform the following 3 steps:
- 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.
Good to know
Reconciliation 9 does not work properly if a correction of the ESL is created, because in the correction no complete return but only corrected lines are created.
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
Good to know!
The reconciliation 10 only makes sense for a company with the constant fiscal year.
Reconciliation 10 calculates the variance between the specified field value of the current month and the average mean value of this field over the last 12 months.
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 12-13: Plausibility check
Good to know!
These reconciliations make sense only if the company has a right to full VAT deduction.
Plausibility check for reverse charge
This reconciliation checks whether the tax value that applies to the reverse charge turnover matches the value in the input tax field that is applicable to the reverse charge turnover.
To do this, the VAT@GTC compares whether the tax in the corresponding fields in the declaration (in Germany these are fields 47, 74, 85) matches the input tax value (which is shown in field 67 in the German advance return).. Deviations can result from rounding differences (e.g. if the tax base is considered as correct). In addition, the difference may result from the fact that input tax is not deductible for certain circumstances or tax codes.
Plausibility check intra-community acquisitions / Input tax
This reconciliation checks whether the tax value that is applied to the intra-community acquisitions matches the value of the input tax that is applicable to the intra-community acquisitions.
For this purpose, the VAT@GTC compares whether the tax assigned to the intra-Community acquisitions (identification in Germany using the advance return fields 89a, 93a, 98 and 96) matches the input tax value (which is shown in the German advance return in field 61). Discrepancies may exist due to rounding differences (e.g. if the assessment basis is considered correct). Furthermore, the difference may be due to e.g. a penalty tax within the meaning of § 3d S. 2 UStG or due to the fact that input tax is not deductible for certain circumstances or tax codes.
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
In the area of reconciliations (master data), the option to hide zero values from the reports can be switched on and off for reconciliations 3 to 5. The option must be selected separately for the report RFUMSV10 as well as for RFBILA. By switching on the option, the result of the respective voting is slimmed down so that rows without values are no longer displayed.