Financial inconsistencies

Modified on Wed, 12 Nov at 11:33 AM

Disclaimer

All screenshots in the article were taken in the Dutch version of Yuki.


While doing accounting in Yuki, sometimes “human” errors occur.

The nice thing about Yuki is that the software provides various tools and checks, such as the Automation Monitor and Quality Monitor, to gain real-time visibility of these so-called errors and to be able to resolve them immediately.

For example, Yuki also has a set of 53 types of different checks called “Inconsistencies.” An inconsistency actually means that certain financial facts within the accounts do not match reality.


Only a user with a “Back office” role in the domain can view the list of financial inconsistencies and, if necessary, take action.


This article describes why these inconsistencies occur and how to easily resolve each type of inconsistency.  


After resolving, the inconsistencies and the red triangle may continue to show for a while despite the fact that you have refreshed the inconsistencies. The red triangle is often gone by the next day.


ATTENTION!

It is important to know that some types of inconsistencies are rare or very rare. Should you encounter them in an administration and the solution is not in this article, please contact the Yuki Support team!


To open the overview with the financial inconsistencies:

  • At the top of the screen, click on the red triangle behind the domain name


    OR

  • Hover your mouse over the Back Office icon in the navigation bar, then click on Inconsistencies.


The following screen is opened:



Use the menu below to quickly jump to the description and resolution of a specific inconsistency:


4 Financial links with inconsistent matches

This inconsistency relates to an automatically generated journal entry. To resolve this inconsistency, it is important to delete the journal entry. This action does not affect any previously closed financial year. 


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the relevant journal entry.
  • Click on the screwdriver icon to indicate that Yuki may fix the inconsistency itself.

5 Financial links with inconsistent contact for matches

This inconsistency relates to an automatically generated journal entry. To resolve this inconsistency, it is important to delete the journal entry. This action does not affect any previously closed financial year. 


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the relevant journal entry.
  • Click on the screwdriver icon to indicate that Yuki may fix the inconsistency itself.

8 Transactions with no document or bank statement

This inconsistency can occur while (re)importing a bank statement with a large number of transactions.


When you (re)import transactions into Yuki, Yuki not only places them on the relevant bank account, but also looks at each transaction for any bank processing rules and whether a transaction can be matched directly with e.g. an invoice. When it comes to a large number of transactions, this can take quite some time.


To prevent Yuki's systems from crashing or overloading, there is a mechanism built into Yuki that shuts down processes that take too long. This can result in these kinds of ghost transactions that are partially but not completely deleted (read: reversed). The mechanism aborted the process for (re)importing the transactions while it wasn't quite finished. 


This inconsistency can also be caused if, during the (re)import process, you click the 'Reimport' button again after a certain amount of time while the current (re)import is still in progress. Yuki will first “roll back” all transactions that have already been processed, before starting to (re)import the transactions again.


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the relevant entry. 
  • Click on the screwdriver icon to indicate that Yuki may delete these transactions.

9 Transactions with inconsistent VAT code and VAT type

This inconsistency occurs when for the GL account the option 'Apply VAT' is disabled and a VAT code is selected via the option 'Book directly into expenses'. The VAT entry is correctly not made by Yuki, however, the selected VAT code is remembered by Yuki behind the scenes causing the inconsistency.


In future, by making the entry via the 'Other transactions' option (where no VAT code needs to be selected) Yuki will not give inconsistency. 


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the affected transaction. 
  • Select the transaction by clicking on the description
  • Open the transaction by selecting what appears under Statement line
  • In the opened transaction, click on the pencil icon at the top left to undo any matching. 
  • Click on the Save button.
  • Then click on the Actions button. 
  • Book this transaction through Other transactions and then match it again.

10 Bank statement lines without transactions

This inconsistency is caused by posting a (manual) bank statement or cash statement where no GL account is specified for one of the transactions. Yuki therefore does not know to which GL account the transaction should be posted. This causes the transaction to be posted to all bank and cash accounts, as it were. 


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the transaction in question.
  • Select the transaction by clicking on the description
  • Change the statement or cash statement by specifying a GL account for the transaction in question.


ATTENTION!

This may affect the annual figures for completed financial years.


12 Financial documents without transactions

This inconsistency occurs when a document is incorrectly processed by Yuki as a purchase or sales invoice without specifying a GL account. Yuki does not know which GL account the expense or revenue should be posted to. 


Solution

To resolve the inconsistency, go through the following steps::

  • Click on the red number behind the inconsistency to go to the relevant document. 
  • Select the document by clicking on the description
  • In this case, you can set the document type to Standard because it is generally an insurance policy overview or other document that does not contain financial transactions/entries.

14 Invoices with inconsistent VAT on invoice lines

This inconsistency is caused by accounting for the invoice in two different VAT accounting periods. 


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the document in question. 
  • Select the document by clicking on the description
  • Change the document type Purchase invoice to document type Sales invoice.
  • Then change the invoice and save it. 
  • Finally, change the document type again to document type Purchase invoice.

15 Invoices with inconsistent VAT transactions

This inconsistency is caused by accounting for the invoice in two different VAT accounting periods. 


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the document in question. 
  • Select the document by clicking on the description
  • Change the document type Purchase invoice to document type Sales invoice.
  • Then change the invoice and save it. 
  • Finally, change the document type again to document type Purchase invoice.

17 Bank documents without transactions

This refers to an inconsistency on a statement that is not yet complete because no transactions have been entered. The inconsistency can also occur when a document is booked as a cash statement when there is no cash in the administration. 


Solution

To resolve the inconsistency, go through the following steps:: 

  • Click on the red number behind the inconsistency to go to the relevant cash statement/statement. 
  • Select the cash statement/statement by clicking on the description
  • Fill in the missing transactions in the statement or delete the statement/cash statement if it is incorrect.

22 Bank statements with inconsistent balance

This inconsistency can have several causes:

  • there are duplicate transactions
  • there are missing transactions
  • there is an error in the bank file/statement
  • the opening balance of the bank account has not been entered.
    As a result, the opening balance of the bank account does not match the closing balance. It may also be the case that the bank balance does not match the check performed on it, Yuki also pays attention to whether these transactions are actually booked in the administration.


Solution

  • Click on the Bank icon in the navigation bar. Yuki will show a warning icon next to the bank account in which the inconsistency is located.
  • Open the bank account by clicking on the date and in the now-opened screen, select All years as the period of the transactions.
  • It is also important that you do not look per statement line but per statement. To do this, click on the appropriate button:


    Two of the bank inconsistencies you may see are the following:
    • From the first statement date, the lines are colored red (with a blue line between them, if applicable).

      In this case, there is simply no matching opening balance filled in for the relevant account. You fill it in by clicking on the pencil at the top left and filling in the opening balance. Yuk now automatically generates a general journal entry in the background.

    • From any given date, the lines are colored red.
      In this case, compare the closing balance of the black line with the opening balance of the red line that is above it. The red line indicates that there is an error from that date. Transactions may be missing from the data between the black and red lines and need to be submitted or resubmitted..


However, there may also be a number of other banking inconsistencies.

For a detailed description of these inconsistencies, see article Bank inconsistencies general.


If you cannot find the cause of the inconsistency, please contact the Yuki Support team.


25 Companies with invalid start date

This inconsistency arises because the start date of the administration is set to a certain year and there are opening balance sheet entries in the administration from after this date.


The inconsistency may have been caused by the administration’s start date being changed at some point.


To find the opening balance sheet entries:

  • Click on the Financials icon in the navigation bar and then select General journal.
  • In the now-opened screen, select All documents incl. automatically generated in the dropdown menu and as period All years.
  • You filter by Type to see all the opening balance entries.


Solution

There are two ways to resolve this inconsistency:

  • On the Administration tab, in the company profile, change the start date of the administration to 01-01-2024
  • Change the date of the opening balance sheet entry to 31-12-2023.

26 Non-opening balance sheet transactions before company start date

This inconsistency is caused by the fact that invoices should have been entered in an opening balance sheet through the corresponding suspense accounts, but this was not done. The invoices were processed in 2023, after which the start date of the company changed from 2023 to 2024.

The tricky part about this is that when Yuki adjusts the start date, it can't estimate whether previously booked invoices should be processed as an opening balance sheet entry or not.


Solution

This inconsistency cannot be solved by clicking on a button. The relevant invoices must be removed from the administration and then entered in the opening balance sheet.

It is indicated that the administration is kept as of 01-01-2024, therefore no entries other than opening balance sheet entries for this start date may be processed. Yuki therefore expects you to do an import of the opening balance sheet on 31-12-2023 when you start the administration in Yuki on 01-01-2024.


27 Inconsistent VAT return amounts

The inconsistency with regard to the VAT amounts may arise because one or more invoices have been moved or removed from a closed VAT return.

This also creates a difference in the Print form of the VAT return and the normal Form. The Print form is the form that has actually been sent to the tax authorities. The amounts listed here were actually paid.


Here is an example:


Print form



Normal Form



In this example, an excessive amount of input tax was used as the basis of the VAT return, which means that the amount to be paid is unfairly low. This must ultimately be offset against the supplementation of the relevant year. Yuki cannot make the booking in the background.


Solution

This booking needs to be made manually via a general  journal entry.

However, only Customer Support can place this manual general journal entry in the appropriate time frame. Therefore, for this inconsistency, contact the Yuki Support team.


28 Opening balance transactions after company start date

The inconsistency is caused by the invoices being posted to the suspense account opening balance with a posting date after the start date of the administration. Yuki automatically makes these entries when the date of the invoice is before the start date of the administration. The starting date of the administration has probably been adjusted once and this situation has arisen.


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the relevant document.
  • Select the document by clicking on the description.
  • At the top of an invoice entry, click on the Reprocess financial entries button so that the invoice is processed again, so that it is posted to the correct GL account.




33 Sales VAT used for purchases or purchase VAT used for sales

This inconsistency is probably caused by an incorrect automatic entry.


Solution

To resolve the inconsistency, go through the following steps:

  • Click on the red number behind the inconsistency to go to the document in question. 
  • Select the document by clicking on the description
  • Change the document type Purchase invoice to document type Standard.
  • Then change the invoice and save it. 
  • Finally, change the document type again to document type Purchase invoice.

34 Transactions of 2010 sales invoices with VAT code ´export within EU´

This inconsistency is caused by a posting to GL account '18610 Supplies to countries within the EU' with VAT code 'Export inside the EU'. This GL account and VAT code were intended for the old regulations.

The booking in question is now not showing up under 3b in the VAT return and in the ICP declaration. The incorrect VAT code is the cause of this.

As of 2010, the new regulations apply, and GL account '18611 Supplies to and/or services in countries within the EU' must be used with VAT code 'Export of goods inside the EU' or 'Export of services inside the EU'.


Solution

To resolve the inconsistency go through the following steps:

  • Click on the red number behind the inconsistency to go to the document in question. 
  • Select the document by clicking on the description
  • Now specify in the invoice the correct GL account '18611 Supplies to and/or services in countries within the EU' with the correct VAT code 'Export of goods inside the EU' or 'Export of services inside the EU'.


ATTENTION!

This may affect the annual figures of closed financial years and returns.


35 Zero amount transactions

This inconsistency is caused because the invoice amount and VAT amount may not match. Also, Yuki does not allow zero amounts. 


Solution

To resolve the inconsistency, go through the following steps: 

  • Click on the red number behind the inconsistency to go to the document in question.
  • Select the document by clicking on the description.
  • Delete the invoice line with amount €0 or adjust the VAT amount to €0.

36 Inconsistenties in VAT

This inconsistency is caused by a difference between the VAT return and the corresponding GL account. For example, this could be caused because you submitted the VAT return to the tax authorities outside of Yuki.


Solution

We recommend contacting the Yuki Support team for this inconsistency.


37 Transactions linked twice to the same transaction

This is a somewhat trickier inconsistency. One of the causes of this inconsistency is the Smartmatching performed by Yuki at the end of an interim import. This involves matching statement lines to multiple general journals or invoices. The journal entry also indicates this. 

The incorrect matching of general journals or invoices to bank transactions must be undone one by one. Interim imports were made and the transactions in question may have already been present in the administration. This is because during the interim import, a statement line is created with both the general journal or invoice but also with the transaction.


Solution

To resolve the inconsistency go through the following steps:

  • Click on the red number behind the inconsistency to go to the document in question. 
  • Select the document by clicking on the description. If all is well, you can open the details on the left via the 'greater than' sign > the details. 
  • Now click on e.g. the Purchase invoice at the top left. The invoice will now be displayed where you can view what was matched to the invoice at the time via the green square
  • Disconnect the match by removing all check marks. 

38 Linked VAT transactions with incorrect VAT type (in general journal entry)

This inconsistency is caused by an automatic entry being created when moving a balance to another account. 


Solution

To resolve the inconsistency, go through the following steps: 

  • Click on the red number behind the inconsistency to go to the relevant document/journal entry. 
  • Click on the screwdriver icon to indicate that Yuki may fix the inconsistency itself.

39 Transaction lines with multiple financial links

This inconsistency occurs when a bank transaction is mismatched with another transaction in some way. 


Solution

To resolve the inconsistency, go through the following steps: 

  • Click on the red number behind the inconsistency to go to the transaction(s) in question. 
  • Click on the Bank icon in the navigation bar and then click on the bank account where the transaction occurred
  • Click on the black trash can icon behind the transaction to mark it as duplicate and delete it. 
  • Click on the Bank icon in the navigation bar and then select Electronic statements.
  • In the now-opened screen, click on the Duplicate lines button and reimport the transaction. 


40 Transactions linked to standard document

This inconsistency arises because financial transactions are linked to a document of the Standard document type. A standard document is used for e.g. annual statements or insurance policy documents, no financial transactions should be linked to this document type. 


Solution

To resolve the inconsistency go through the following steps::

  • Click on the red number behind the inconsistency to go to the document in question. 
  • Select the document by clicking on the description
  • If required, leave the document type on Standard if it is e.g. a policy statement or another document that does not contain financial transactions/bookings.
    OR
  • change the document type to the required type and process the document.

43 Zero transactions generated for bank statement lines

This inconsistency is caused by zero lines in the entries. This can occur, for example, when the base of a VAT or interest rate is so low that the VAT or interest to be remitted is €0. 


Solution

To resolve the inconsistency go through the following steps: 

  • Click on the red number behind the inconsistency to go to the relevant transaction. 
  • Open the entry by clicking on the description. Here you can see that there is a zero line in the entry. 
  • Click on Statement line in the upper left corner. 
  • Click on the Actions button and then click on Other transactions.
  • Finally, rebook the transaction (manually) by posting it directly to revenue or expenses..

44 Bank statements with inconsistent balance and active import subscription

The inconsistency is caused by inconsistency “22 Bank statements with inconsistent nalance” and resolves itself automatically after resolving this inconsistency.


45 Documents linked to multiple VAT refunds

This inconsistency is caused because the entry of the document is included in two different VAT accounting periods. This could be a VAT refund or a correction in the VAT return. 


Solution

To resolve the inconsistency, go through the following steps::

  • Click on the red number behind the inconsistency to go to the relevant document. 
  • Select the document by clicking on the description
  • Change the document type Purchase invoice to document type Sales invoice.
  • Then change the invoice and save it. 
  • Finally, change the document type again to document type Purchase invoice.

46 VAT returns with an amount that is not consistent with the total amount of all linked transactions

This inconsistency is caused by one or more transactions that have been moved or transferred from one GL account to another GL account. The transaction(s) in question must be reversed/posted back to the original GL account to eliminate the inconsistency.


Solution

To resolve the inconsistency go through the following steps:

  • Click on the red number behind the inconsistency to go to the relevant transaction. 
  • Open the entry by clicking on Description
  • Now click on the Actions button and then click on Other transactions.
  • Then, manually rebook the transaction to the original GL account.

47 Year-end corrections with an invalid date

This inconsistency is caused by making a year-end adjustment on the first day of the year. An end-of-year adjustment should always be posted on the last day of the calendar year. 


Solution

To resolve the inconsistency, go through the following steps: 

  • Click on the red number behind the inconsistency to go to the corresponding year-end correction. 
  • Open the entry by clicking on Description
  • Change the date to 31-12-....

    ATTENTION!
    The inconsistency check does not take into account the ISO calendar and broken financial years. For this reason the Inconsistency will always be shown. If you still want to resolve the inconsistency with a workaround then, if required, you can change the year-end correction to General journal type instead of Year-end correction.

49 Invalid VAT codes in VAT returns

This inconsistency checks whether VAT codes were used for certain bookings that should not have been used for that specific booking. Think of older invoices that were booked with the high VAT rate of 19%, which is no longer valid after 2012.

The invoices processed with, for example, the 19% VAT code may have been deleted in the meantime. Yuki will then automatically create a contra-entry for the VAT. The inconsistency arises now because the VAT code was naturally also used in this reversal.


Solution

To resolve the inconsistency go through the following steps: 

  • Click on the red number behind the inconsistency to go to the document. Here you can immediately see which VAT rate has been used. 
  • Click on the Settings icon in the navigation bar and then select VAT rates.
  • Change the end date of the VAT rate to e.g. 31-12-2023 or deactivate the VAT code.

50 Invalid workflow documents

This inconsistency is caused by a sales invoice generated based on the Sales functionality entering the workflow incorrectly. 


Solution

To resolve the inconsistency, go through the following steps: 

  • Click on the red number behind the inconsistency to go to the document in question. 
  • Click on the screwdriver icon to indicate that Yuki may fix the inconsistency itself. This will return the document to the Completed status.


Was this article helpful?

That’s Great!

Thank you for your feedback

Sorry! We couldn't be helpful

Thank you for your feedback

Let us know how can we improve this article!

Select at least one of the reasons
CAPTCHA verification is required.

Feedback sent

We appreciate your effort and will try to fix the article