Product Comparison

Discover which one of our products is going to revolutionise your taxes.

LimeLyte Logo

The full tech suite for complex indirect tax needs. Includes inFlyte automation and LimeLyte tax analytics.

  • A feature listed here
  • A feature listed here
  • A feature listed here
  • A feature listed here
  • A feature listed here
Book a demo Compare features ↓
Transactional
Manually Entered Tax Details - Receivables

User case scenario:

There are many reasons that tax details are entered manually, but these are the two most common that we come across:

  1. The standard process is for the User to add or amend tax on an invoice (not applicable where using InFlyte from Innovate Tax)
  2. User is unaware of how to correctly change the tax so instead makes changes in the tax details screen

It is important to track these instances this as Users should never be using the tax details screen, as this means tax rules will not be able to calculate correctly.

Our solution:

This represents a huge risk to your business as there is no control over what tax is applied, potentially resulting in incorrect tax treatment.

A good example of how this page can be used came from a previous client project.

During the implementation of our inFlyte solution, we used LimeLyte to audit existing data. We discovered that one of our client’s Users had been manually entering tax details of an OLD tax regime; this meant all affected invoices had been missed off their tax return. Fortunately, our discovery helped our client to avoid a potentially damaging fine for non-compliance.

Manually Entered Tax Details - Payables

User case scenario:

There are many reasons that tax details are entered manually, but these are the two most common that we come across:

  1. The standard process is for the User to add or amend tax on an invoice (not applicable where using InFlyte from Innovate Tax)
  2. User is unaware of how to correctly change the tax so instead makes changes in the tax details screen

It is important to track these instances this as Users should never be using the tax details screen, as this means tax rules will not be able to calculate correctly.

Our solution:

This represents a huge risk to your business as there is no control over what tax is applied, potentially resulting in incorrect tax treatment.

A good example of how this page can be used came from a previous client project.

During the implementation of our inFlyte solution, we used LimeLyte to audit existing data. We discovered that one of our client’s Users had been manually entering tax details of an OLD tax regime; this meant all affected invoices had been missed off their tax return. Fortunately our discovery help our client to avoid a potentially damaging fine for non-compliance.

Tax Calculation Difference - Receivables

User case scenario:

If a User enters either a Tax Control Amount or manually changes the tax details with a Tax Rate % that is different to the expected Tax Rate %, this can cause substantial under or over-payments of tax.

In the UK for example, the domestic tax rate is 20%, which would be the expected system Tax Rate % for a UK domestic invoice. However, if the Tax Rate % were recorded at 19.9% (-0.01% difference), this would be identified as a potential error.

Our solution:

It is important to see these occurrences as Users in AR should never amend the tax amount; the tax should only ever be changed by choosing a different tax rate.

Say for example that a User wants to change the Tax Amount or Tax Rate % but instead of changing the Tax Rate % itself the User adjusts the Tax Control Amount or even the monetary amount.

This can cause issues with tax reporting but could also present problems during an Audit as business are liable for ensuring that the correct tax is always charged.

Tax Calculation Difference - Payables

User case scenario:

If a User enters either a Tax Control Amount or manually changes the tax details with a Tax Rate % that is different to the expected Tax Rate %, this can cause substantial under or over-payments of tax.

In the UK for example, the domestic tax rate is 20%, which would be the expected system Tax Rate % for a UK domestic invoice. However, if the Tax Rate % were recorded at 19.9% (-0.01% difference), this would be identified as a potential error.

Our solution:

Tax Calculation differences happen for many reasons, but the most common cause is that a User has received an invoice where the tax amount given on the invoice does not match the tax amount calculated in Oracle. This is usually down to a rounding difference, e.g. the supplier has charged the business £19.99 instead of £20 tax.

It is  important to track these for many reasons:

  1. The User could just be changing the Tax Amount instead of the Tax Rate % – this can cause issues with reporting and this risk can be mitigated
  2. To identify problematic invoices from suppliers with recurrent rounding differences, to avoid over or under paying tax to this supplier.
Transactions with Offset Tax Missing

User case scenario:

When an invoice is processed in Accounts Payable with the offset tax line missing, this could be due to a manual cancellation of the Offset Tax Line or the ‘Allow Offset Taxes’ option is not ticked on the Supplier Site.

Our solution:

Generally, this occurs when:

  1. Supplier setup is incorrect
  2. User has erroneously deleted the Offset Line as they believe that it shouldn’t be there (they may think it’s a glitch or perhaps that the tax charged is wrong.

 

It is important to track this as the wrong tax could be being applied to these invoices/paid to suppliers. This will also impact your reporting as the wrong tax rate will have been charged.

Transaction Lines with Unknown Tax
-

User case scenario:

This code might be selected by a User when they are unsure of what the Tax Rate % should be for the respective transaction.

The ‘Tax Unknown’ code is only for exceptional use in the event the User has no other option.

Our solution:

‘Tax Unknown’ exists purely for compliance reasons; it is better that the User adopts this code than to use an incorrect code.

If the code is used, the transaction is immediately flagged for review by the Tax Manager, who can advise on the correct tax treatment.

This code is only available where businesses have procured both inFlyte and LimeLyte, as it is part of a workflow approval process between the two technologies.

AP Lines with No Product Type

User case scenario:

This occurs when a User manually enters an AP invoice without specifying whether the item being bought is a GOOD or SERVICE in the ‘Product Type’ field.

Either no Product Type has been defaulted onto the Line or a User has not chosen a product type on the Line.

 

Our solution:

Indicating whether an invoice is for Goods or Services is important for countries such as Belgium, where the requirement exists to designate between the two on every transaction for reporting purposes.

For businesses that sell or purchase outside of that operating country (non-domestically) -especially in the EU -will need to split between Goods or services for reporting.

This page flags any transaction that does not specify the Product Type for correction by Tax Managers.

AP Tax GL Code Incorrectly Used

User case scenario:

This generally happens if, instead of selecting an expense account, the User has selected a tax account on the item line under the ‘Default Distribution Amount’ field.

Our solution:

In the majority of cases, this issue has occurred through manual User intervention, resulting in an incorrect selection on the distribution segment or line. Similarly, this happens when incorrectly trying to create a tax only invoice.

It is important that this is discovered and corrected as item lines should always go into the expense account and never be put to a tax line; this will cause issues with accounts, accounting and reporting.

This page pinpoints these transactional errors for the required adjustments.

Transaction Lines with No Tax Line

User case scenario:

This is a User input issue where the User enters a transaction item line and not calculated tax. This could be due to the User manually cancelling the tax line or the ‘Allow Taxes‘ flag not being set to ‘Yes’ on the Supplier Site.

Our solution:

There are two reasons why this could occur, which are identified within this page:

  1. The User has manually cancelled the tax line. This could be because they believe no tax should be calculated, e.g. a 0% rate, however all tax should be calculated no matter the percentage rate. This is common in territories where VAT is a relatively new obligation, e.g. Middle East, where they are not used to seeing tax line.
  2. The ‘Allow Offset Tax‘ flag is not set to ‘Yes’ on the Supplier Site; in this event, tax will not be calculated. This is important because every transaction should have a tax line, even if no tax is charged on this transaction, i.e. it is exempt or out of scope, as this is a reporting requirement.

In the event of an audit, it is not sufficient only to show transactions without a tax line – it must be demonstrated and justified to the relevant Tax Authority WHY no tax was charged on this line.

Invoice on Tax Hold

User case scenario:

When a transaction is put on a tax hold in the system there are a number of reasons for this.

When an invoice is on hold it cannot be processed and therefore not paid.

Our solution:

This page is an incredibly useful tool to see all invoices that have been put on hold for a tax reason.

This allows full transparency to the Tax Manager who might not otherwise be aware of held invoices. They are able to take remedial actions to look into the reasons for the hold and release for payment.

In doing so, organisations can avoid potential late payments or business disruption due to non-payment of services to third party suppliers.

Transactional Analytics
AP Goods and Services Mismatch
-

User case scenario:

TEXT

Our solution:

TEXT

AP Invoices with Tax Overrides Used

User case scenario:

Occurs when a User enters a ‘Tax Override‘ on the AP line.

Our solution:

This page shows how frequently tax override codes are used.

With an automated solution, the amount of instances where an override is required should be limited, so consistent practice of manual overrides could indicate further automation is needed.

For example, it might be that a certain supplier invoice is always exempt, which could be rectified by an adjustment to the automation.

For Tax Managers, this page could also show if Tax Teams are wrongly using the override function, to identify areas for training.

NB This page requires the organisation to use the ‘Fiscal Classification Code’ field in AP.

AP Domestic Tax Rate Invoice In A Foreign Currency
-

User case scenario:

When a foreign currency is used on a domestic rate invoice, e.g. the company is a UK organisation that has an invoice from a UK supplier, which has charged in Euros; this should instead be a domestic UK-to-UK standard 20% rate transaction.

Our solution:

Occurs as a Supplier issue which invoices in a foreign currency when it should be a domestic invoice.

This page provide Tax Teams with insight into repetitious Supplier errors for their correction.

AP Invoices with Tax Hold and Release

User case scenario:

When an invoice has been put on a tax hold, this could be due to several reasons.

This page will show you those transactions that have been put on a tax hold and then later released.

Our solution:

There are many reasons why an invoice could be put on hold, for example there is a tax variance, or difference between the Header and Line amount.

This page is useful for invoice case management as well as team management, as it shows all the held invoices that have been subsequently released and by which User.

AP Invoice Distributions with Tax Variances

User case scenario:

When a User processes an AP invoice with a ‘Tax Variance‘ as this can be ignored if the amount is minimal and does not prompt closer inspection.

This page will provide a list of these transactions to spot if under/overpaying Suppliers.

Our solution:

This function can be used to review any transactions that have a variance in the distributions, in case these transactions need investigation or not enough tax is going into the correct tax account.

Crucially, this also helps Tax Managers to monitor teams to ensure correct practice is adopted, i.e. that even small variances in tax amounts can have a damaging, cumulative effect.

AP Lines with Foreign Tax Codes
-

User case scenario:

This page flags whenever a User enters an AP invoice using one of Innovate Tax’s (custom) tax overrides of NO RC FOREIGN TAX or FOREIGN TAX (expenses).

Our solution:

The benefit of this page is the ability to view all of your foreign expenses and instances in which the NO RC FOREIGN TAX has been used and changed (as this has a 30% rate attached to it which is designed to be manually changed to the correct percentage).

AP Self-Assessed Transactions with Self-Assessed Tax Applied

User case scenario:

It is important to be able to see these transactions as the tax is not visible on the invoice lines (only in Tax Details) so Users may not be aware what tax has been charged.

Our solution:

This page shows any AP transaction where at least one of the lines has been ‘Self-Assessed‘ for tax, in order to verify that the correct tax is being applied – particularly useful for tax within the United States.

AP Invoices with Self-Assessed Incongruent Tax Lines

User case scenario:

It is important to see these to check why one line has been self-assessed and the other hasn’t, e.g. it could be the supplier forgot to charge tax on one line or that one line is exempt.

Our solution:

This page shows whenever a User enters an AP invoice with multiple tax lines with a mixture of ‘Self-Assessed‘ and ‘Non-Self-Assessed’ tax lines.

As a result, the User is now able to review such occurrences in order to know if this was the correct treatment or not – particularly useful for tax within the United States.

AP Invoices with Mixed Sales and Use Tax Treatment

User case scenario:

Our solution:

AR Invoices with Tax Overrides

User case scenario:

It might be important for your organisation to identify when a ‘Tax Classification Code’ has been used to override the tax on an AR line, particularly if there is automated tax logic/rules in place to prevent this.

Our solution:

This page shows occurrences when a User enters a ‘Tax Classification Code‘ on the AR line to override the tax.

This can be incredibly useful, in particular to see how frequently tax classification codes are used to draw insights, e.g. it might be that a certain transaction is always exempt and this could lead to further automation being needed, or Users need more training.

AR Tax Only Invoices

User case scenario:

Our solution:

AR Transactions Where Ship-To and Bill-To Countries Differ

User case scenario:

Our solution:

AR Imported Transactions Missing TCC

User case scenario:

Our solution:

PO Tax Rate Different from AP Invoice

User case scenario:

Our solution:

Domestic or Non-Domestic Tax Codes Used
-

User case scenario:

Our solution:

Source
Supplier Invalid Address - US

User case scenario:

Our solution:

X
X