For information on when to apply the reverse charge VAT in Austria, Follow this link
What are the tax implications of doing a mid-month go live?
From a Oracle ebusiness tax point of view, you could be heading for a lot of complications for that first months reporting. It’s rare that you won’t have any issues with the migrated data and if done correctly, the migrated data will retain the legacy tax codes but any newly entered transactions will use the new tax rates. So how will this look when you try and run the VAT reports for that month as you are pulling data from different transactions and the old legacy rates are unlikely to be linked to the correct reporting codes that are needed for a lot of the tax reporting. I would always suggest that it is better to run the old VAT reports in the old system and then the new reports in the new system and this way, all the open migrated transactions should have already been processed for the monthly VAT returns leaving the new month and the new eBTax solution to handle the new transactions and the next VAT return. But this won’t be possible with a mid-month solution – or is it? please discuss.
ever get this error when first trying to log into Oracle ebusiness Tax Manager?
“You have encountered an unexpected error. Please contact the System Administrator for assistance”
This is because there is no default Operating unit assigned to the tam manager profile options.
Unless my client has an extremely well refined 11i ERP solution working without fault with almost no customisation nor any country localisations, I would always say that a re-implementation is the right way forward. Time and time again, when working on upgrade projects, things are always a lot harder than if the project was being implementeded. I liken an 11i to R12 project to a house renovation. Consider 11i to be your house now and R12 to be the super environmentally friendly completely modern house of the future. If you have a very basic house that has been well constructed and has a great layout then making the renovation is straight forward, however, if that house is old, of a poor design and construction that needs all the pipe work and wiring replaced, making it extremely hard to get the underfloor heating in that you wanted, surely it would be better to knock it down and start again? Of course this is where my comparisons end because the costs of knocking down a house are usually the biggest factor as are the costs of any IT project, the 11i to R12 upgrade being one of them. But will the cost be any greater by doing a reimplementation instead of an upgrade? In the long run, with the delays to the project or the late surge in additional resources to fix the issues, update the customisations and ensure that the localisations are working to meet local fiscal policy, the upgrade becomes as costly, if not a higher cost than a clean re-implementation!
The challenged faced by any company implementing a new ERP solution, whether a single entity or a global conglomerate, is to capture the complex business requirements and yet keep the structure as simple as possible. Creating a highly complex organisation structure is likely to lead to greater data processing needs as well as a more labour intensive maintenance requirements. There is also a risk that the solution initially designed to help the company, ultimately leads to issues that end up consuming more resource.
Any solution architect will be considering this when they design the organisation structure deciding the best approach for the number of ledgers, what legal entities will use these ledgers and how many operating units will be needed to capture the data from the sub ledgers such as the Payables or Receivable modules. Continue Reading
A recent client of mine had a heavily customised eBTax solution which was heavily intertwined with the rest of the ERP setup. The problem is that the original tax solution was poorly designed in the first place and where eBTax functionality existed to handle most of the client’s requirements, it was not used and so customisations were used instead to drive the tax. Now we are faced with the task of correcting the eBTax solution to a fully automated one but we have to take the approach like peeling back the layers of an onion as we don’t know how deep the customisations go and whether removing the customisation effects other functionality.
EU ministers have given the go ahead for 11 eurozone members, including France and Germany, to prepare a new financial transactions tax.
This of course can be accommodated by the eBTax engine, but will there ever actually be a requirement to calculate this new Financial Transaction Tax in Oracle?
The reason why I say this is that the majority of financial institutions use their own bespoke solutions to manage the trades taking place, and this is usually only recorded in Oracle as a GL entry. Is it even possible expect that Oracle could handle the huge volumes that are generated by the trades?
Having worked at some of the biggest financial institutions, I am fully aware of the ’empire’ building that takes place by certain individuals so that their own billing solutions will never be replaced, but these banks and brokerage firms should start consolidating their back end systems, so that instead of having 14 separate systems all generating invoices to their clients, they should feed the transactional data into Oracle and then have just one system creating the invoices. Not only will this reduce the maintenance and time taken for month closing but will open up the way to allow Oracle to be used for the tax calculation including both VAT and the new Financial Transactions Tax.
One of the primary drivers for the AGIS (Advanced Global Intercompany Solution) module was to ensure that the correct tax was calculated for transactions that were created by journals. The problem, from an eBTax point of view, is that the useable tax information is restricted by an AGIS generated transaction that originates from GL.
Take for example the requirement under EU law to separate out the sale of Goods and Service for intra-EU trades. The only way to do this in Oracle, for the Oracle eBusiness (eBTax) tax engine, is to first create a dummy tax rate called ‘SERVICE ITEM’, and then assign this rate to the tax classification code field on an AR memo line. In turn, this memo line is linked to the AGIS Transaction Type. Rules are then used to drive the correct tax, i.e. if the transaction is between two EU entities and the SERVICE ITEM is used then ‘Intra EU Sales Services’ will be calculated rather than the ‘Intra EU Sales Goods’.
When the AGIS AP invoice is created, you need to pull the same Tax Classification Code through, i.e. ‘SERVICE ITEM’ so that the correct AP ‘Intra EU AP Sales Services’ is calculated.
But how else can AGIS be used for tax calculations? is there an enhancement to allow not only a memo line to be added to an AR transaction type, but also to allow additional information for tax purposes such as ‘Intended Use’ or the ‘Fiscal Classification’ that can be used by AP and AR?
For a list of EU VAT rates for 2013, please follow this link – EU VAT rates for 2013
It is too late to change R12 to accommodate changes to make the reporting easier but what can be done to Oracle Fusion to enrich the tax reporting so that at the point the tax is calculated, the user knows what tax rate is being used, whether it is a service or inclusive or an asset or even a ‘Self Assessed’ tax immediately.
The following are the list of countries that currently validate the VAT number when it is entered.
Currently, Switzerland has incorrect validation
REM | (26 countries) |
REM | AT – Austria |
REM | BE – Belgium |
REM | DK – Denmark |
REM | EE – Estonia |
REM | FI – Finland |
REM | FR – France |
REM | DE – Germany |
REM | GR – Greece |
REM | IE – Ireland |
REM | IT – Italy |
REM | LU – Luxembourg |
REM | SK – Slovakia |
REM | NL – Netherlands |
REM | PL – Poland |
REM | PT – Portugal |
REM | ES – Spain |
REM | SE – Sweden |
REM | GB – United Kingdom |
REM | CH – Switzerland |
REM | RU – Russia |
REM | HU – Hungary |
REM | BR – Brazil |
REM | AR – Argentina |
REM | CL – Chile |
REM | CO – Colombia |
REM | TW – Taiwan |
REM | |
REM | MT – Malta |
REM | CV – Cyprus |
REM | LV – Latvia |
REM | LT – Lithuania |
REM | SI – Slovenia
Once you have set up a tax zone, run the following SQL query – select * from hz_geographies g where g.GEOGRAPHY_USE = ‘TAX’ You will see that the end date is defaulted to 31-DEC-2012 even if you had set no value! On testing it does not appear to have a negative effect on creating tax conditions but its something to be aware of.
A colleague of mine recently called me to ask how to setup offset taxes for receivables. I had never come across the requirement before so I was interested to find out why the request came about and it turned out that they only needed it for reporting purposes. So it would be interesting to find out if anyone else has had a similar requirement and if so why? And what other solutions are available for using taxes for reporting only in AR. There is a ‘reporting only’ tax option that can be setup when creating a Tax but this is used for AP purposes only.
I am coming across a situation where a certain type of tax is only applciable if the order amount is over €5000 but how can this be done in oracle ebusiness tax?
With this change, Iceland will have four VAT rates on goods and services:
Another VAT change is that effective 1 January 2013, movie tickets to Icelandic films are no longer exempt from VAT, but are subject to the standard VAT rate of 25.5%.
Effective 1 July 2013, the VAT rate on condoms, reusable diapers, and diaper fillers (custom 9619.0091) will be reduced from 25.5% to 7%.