...
| Table of Contents |
|---|
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. Click on [Run reconciliations] to start the process, the results will be displayed in the same dialogue.
| Tip | ||
|---|---|---|
| ||
If the VAT return is finalised, it is not possible to run the reconciliations. The following message is displayed:
|
In the Reconciliation detail view you can see individual results with different status levels.
The following overview shows different status of the individual reconciliations and the corresponding symbols.
...
Overview
...
Main view in the Reconciliations dialogue – (see figure VAT: Reconciliations)
...
...
No errors/ error corrected/ error ignored
The reconciliation is successful
...
...
...
...
...
Reconciliation contains no errors
Special feature reconciliation 1: Reconciliation contains errors – within autolimit
...
...
...
...
...
Reconciliation contains errors
| Tip | ||
|---|---|---|
| ||
Compulsory reconciliations or shifting of open reconciliations are connected to the resubmissions. |
Reconciliations can be marked as mandatory in the master data in the [Reconciliations] dialogue. If this is the case, findings cannot be moved to the subsequent period. If the reconciliation contains errors, the message [Completion cannot be shifted again] appears. As a result, the VAT return cannot be finalised and cannot be sent.
If the reconciliations are marked as [not mandatory], the number of times these errors can be shifted can be defined in the respective company dialogue under the [Reporting parameters]. If the [The reminder can be shifted XXX/ several times] setting is bigger than 0, the [Completion can be shifted into next period] option is displayed in the dialogue. It has to be activated using the available checkbox. Thus, the open reconciliation for this period is also done in the current resubmission.
| Tip | ||
|---|---|---|
| ||
| PLEASE NOTE: Sometimes it is not possible to shift the open reconciliation into the next period (depends on the settings). However, the processing of the erroneous reconciliations is no longer possible, since the VAT return has already been finalised and sent. It can no longer be opened without a correction which is necessary for the processing of the reconciliation. For more information please go to the section [Resubmission]. |
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.
The values from the [RFUMSV00] are displayed in the reconciliation table in the columns [Assessment base from VAT return] and [VAT form VAT return]. The VAT@GTC calculates the respective tax or tax base for these values and compares them with each other.
...
19%
...
Audit
...
Values from RFUMSV00
...
Calculation VAT@GTC:
...
Reconciliation
...
Tax value
...
190 €
...
1.000 € x 19 % = 190 €
...
190 € / 0,19 = 1000 €
...
If the posted values from the report do not match the calculated values, the reconciliation fails.
...
19%
...
Audit
...
Values from RFUMSV00
...
Calculation VAT@GTC:
...
Reconciliation
...
Tax value
...
50 €
...
1.000 € x 19 % =
190 €
...
50 € / 0,19 = 263 €
...
If e.g. in RFUMSV00 tax base is EUR 1,000 and as the VAT tax amount is EUR 50, the VAT@GTC calculates the tax on the basis of the tax base [EUR 1,000 EUR x 19% = EUR 190] and then the tax base on the VAT amount in RFUMSV00 [EUR 50 ÷ 0.19 = EUR 263]. This reconciliation results in obvious differences (this will be shown in the status).
The calculated values are inserted into the columns [Calculated tax base] and [Calculated tax].
Different adjustment options
Automatic correction
As described in the [Countries – General Information] section, an auto limit can be set for the reconciliation. Amounts within this limit are automatically adjusted during the RFUMSV00 import and their status is set to done with the processing status green. These adjustments are only visible to the user in the change log.
...
Manual adjustment
If there are deviations between [Assessment base from VAT return] and [Calculated tax base] or [VAT from VAT return] and [Calculated tax] and if these are above the set auto limit, manual changes can be made in the [Edit] column.
After selection of the corresponding row, a processing field under the reconciliation table is opened, here you can adjust tax base or tax. In this case, the user has to decide whether the tax base or the tax is decisive for the VAT return.
| Tip | ||
|---|---|---|
| ||
| The adjustment of the tax base or tax depends on the settings made in the master data. If the [Tax] is set as the starting point in the master data, the tax base has to be adjusted. |
...
If the manual changes have been made and saved via [Save 
], the adjusted
reconciliation is displayed as completed in the processing status. The [Rec. result] column indicates adjusted reconciliations with a [
] and error-free reconciliations from the start by a green checkmark [
]. All changes can be viewed in the change log. The changes can also be seen in the VAT return form.
Reconciliation 2: Comparison of G/L account with VAT return
This reconciliation requires a separate G/L account VAT to pay or recover. A G/L account VAT to pay or recover calculated in the VAT return is compared to the balance of the relevant payload account (RFBILA), which has been imported for the current month.
If no payment account is stored, this message appears:
The account from the (RFBILA) can be changed by the user in the master data [Reconciliations: Manage reconciliation accounts] area. In addition to the main import of all balance sheet accounts (usually without IFRS accounts), a separate G/L account VAT to pay or recover can be entered. Make sure that the number and name are the same as the imported account.
| Tip | ||
|---|---|---|
| ||
To ensure the proper processing of the G/L account VAT to pay or recover, filter the account from the list of all imported accounts using the “search function”, copy the number and description into the field. |
The amounts in this reconciliation do not match. Possible reasons:
- Account clearing of the G/L account VAT to pay or recover is not monthly
- Remaining residual amounts on the account
- Shift of account clearings by means of the permanent extension of the filing deadline
The aim of this reconciliation is primarily the process-related derivation of the difference. After the successful reconciliation, it is necessary to adjust the VAT return or the account balance.
Different adjustment option
Adjustment of the Declaration
Amendments of the declaration is an exception (Reason: changes to tax codes or additional entries are made in reconciliation 1 and directly in the VAT return form). 
The selection of the tax code in conjunction with the tax code type is very important for the adjustment, as well as the accurate input of the correction value (please use the exact amount including the sign as specified by the system for every tax code type).
However, it is recommended not to make the adjustment in this reconciliation. Alternatively, do the folowing:
- Apply changes directly in the VAT return form by adjusting the respective tax code in the corresponding box.
- Run reconciliation again - after this, the status should change to [Successful].
Adjustment RFBILA
The adjustment of the relevant the G/L account VAT to pay or recover from the balance sheet is the standard procedure in the case of a reconciliation difference. The respective account is specified by the VAT@GTC. However, another account can also be selected.
The use of the right sign is important for the adjustment. The sign is also specified by the VAT@GTC. As described in the section [Reconciliation 1: Plausibility of VAT amounts in VAT report V00], it is important to be able to derive the process-related difference in process. If this is not the case, the reconciliation should be deactivated for the company.
...
If the reconciliation is set to status [green], there are no notes in the resubmission of the current period (assuming there are no open tasks 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 you in the subsequent reconciliations.
| Tip | ||
|---|---|---|
| ||
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. |
Different adjustment options
Adjustment of V10
The RFUMSV10 must be adjusted to the RFUMSV00. This adjustment does not result in a change to the reporting form, since the RFUMSV10 is not used to create the monthly/ quarterly VAT return (preliminary VAT return) in the VAT@GTC.
...
The RFUMSV00 is not adjusted to the RFUMSV10, since the RFUMSV00 is the standard SAP report for the monthly/ quarterly VAT return (preliminary VAT return) and consequently the RFUMSV10 must be adjusted.
- Select the row.
- Upon selection, the detail view opens in which the RFUMSV00 can be adjusted.
- After saving, there will be no difference in the tax code.
- The amount is automatically copied to the VAT return.
...
Reconciliations 4-6: Completeness check of revenue, expense and balance sheet accounts
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 (VAT = 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 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.
...
| Tip | ||
|---|---|---|
| ||
However, if the deviation is relevant, the value from the RFUMSV10 or the RFBILA must be adjusted. This does not have any direct impact on the VAT return. These adjustments must therefore be made directly in the VAT return. |
| 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 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 finding is not an error (for example, a negative income was booked on the expense account and is therefore not relevant)
- The finding is an error and has to be edited
If the finding is an error, proceed as follows:
The amount must be recorded with the tax code. The editor must perform the following 3 steps:
- If this affects the VAT return, the editor must make an adjustment in the VAT return form.
- The booking to the account in SAP must be cancelled.
- The amount with the correct tax code has to be entered again (please note that this is usually a booking in the subsequent period - this must be taken into account in the VAT return).
...
| 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:
| 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. |
| Tip | ||
|---|---|---|
| ||
| PLEASE NOTE: Sometimes it is not possible to shift the open reconciliation into the next period (depends on the settings). However, the processing of the erroneous reconciliations is no longer possible, since the VAT return has already been finalised and sent. It can no longer be opened without a correction which is necessary for the processing of the reconciliation. For more information please go to the section [Resubmission]. |
Click on [Run reconciliations] to start the process, the results will be displayed in the same dialogue.
| 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.
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.
|
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.
|
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.
| Tip | ||
|---|---|---|
| ||
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. |
| Tip | ||
|---|---|---|
| ||
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].
| Tip | ||
|---|---|---|
| ||
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.
| Tip | ||
|---|---|---|
| ||
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.
| Tip | ||
|---|---|---|
| ||
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. |
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.
| 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 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 you need the amounts reported in the ESL are needed.
The tax code defines what relevant values from the VAT return are used for included in the reconciliation . That is why it is necessary to identify in the [Tax Code] dialogue in the [Master data] main area whether they are relevant for the ESL. Using the form field assignment in the [Mapping of tax codes] dialogue on the basis of the relevant fields. Based on the form field allocation, the VAT@GTC differentiates between the intra-community supply [field 41], reverse charge supply [field 21] and intra-community triangular transactions [field 42]. In the reconciliation the tax bases of the tax codes mapped to these fields are added and compared with the entries in the import dialogue or added up import data.
Run reconciliation
The master data can be used to specify whether the reconciliation is to be carried out during the monthly VAT return or ESL. The deadline for VAT return submission is the basis for decision-making. In the case of a permanent extension of the filing deadline, the ESL (25th of the following month) shall be submitted before the monthly VAT return (10th of the next but one month). The reconciliation therefore makes sense during the submission of the monthly VAT return. If necessary, a corrected VAT return must be prepared.
If the monthly VAT return is submitted before the ESL, the reconciliation must be carried out with the ESL, since both data sets are available then.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 difference
This reconciliation always 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 marklimit, 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 [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. |
Plausibility check
...
for reverse charge
This reconciliation controls 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.
The VAT@GTC controls whether the taxes from the RFUMSV00 under the § 13b-UStG [Inputtax] (identification by means of tax code mapping to monthly return fields 47, 53, 74, 79, 85) match the input tax, identified in the monthly return field 67
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).
Plausibility check 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/ Input tax .
This reconciliation controls 
For this purpose, the VAT@GTC compares whether the tax value that is applied assigned to the intra-community acquisitions matches the value of the input tax that is applicable to the intra-community acquisitions. The VAT@GTC controls whether the taxes from the RFUMSV00 under the intra-community acquisitions (identification by means of tax code mapping to monthly return fields 89a, 93a, 98 and 96) match the input tax value, identified in the monthly return field 61. Deviations can result from rounding differences (e.g. if the tax base is considered as correct).
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. 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.
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.