Fix the leak, not the floor

Picture a kitchen floor that is always wet.

Every morning someone grabs a mop. The floor is dry by nine. By lunchtime it is wet again. So a better mop is bought, a bigger bucket arrives, and someone builds a clever little schedule so the mopping is shared fairly.

Nobody looks at the tap.

It sounds silly in a kitchen. In VAT reporting, it happens every month.

The monthly mop

A customer has the wrong VAT number in Oracle. A tax code that was set up for goods is used for services. An intra community supply is booked with domestic VAT. Small things, at the start.

Then the VAT return is due. Someone exports the data, spots the difference and corrects it. In a spreadsheet, in a reporting table, sometimes directly in the return. The figures tie, the return is filed, everyone goes home.

Next month the same kind of transaction comes in with the same problem. Out comes the mop.

Why the shortcut is so tempting

Let us be fair. Fixing it downstream feels efficient. The deadline is close, an Oracle change needs a ticket, and the person who knows the master data is on holiday. A quick adjustment in Excel is simply faster.

The trouble is what it leaves behind:

• Oracle and the VAT return now tell two different stories.
• The next audit file, SAF T extract or e Reporting submission is built from Oracle, so the error travels on.
• The adjustment lives in someone's spreadsheet, not in the audit trail.
• Next month, someone has to remember to do it again.

And as near real time reporting spreads across Europe, the mop gets slower than the leak. When transaction data reaches the tax authority close to the moment of invoicing, there is no month end left to tidy up in.

Close the tap

The principle is simple, and we repeat it often because it matters: the correction belongs where the mistake was born.

If the VAT number is wrong, fix the customer record in Oracle. If the tax code is wrong, fix the tax setup and correct the affected transactions through the normal Oracle process. Then let the reporting pick up the corrected data.

That is exactly how itax4apps works. It sits next to Oracle, not inside it, and never becomes a second administration. The VAT Summary reconciles your reporting with the general ledger and shows where the differences are. The fix happens in Oracle. The next refresh shows that it worked.

Which brings us to this month's question

If the fix belongs in Oracle, who actually makes it? Tax spots the problem. Finance owns the ledger. IT owns the system. The master data team owns the customer record.

That is why our November theme is Who Owns the VAT Data? A leak only gets fixed when someone feels responsible for the tap.

The cheapest error to fix is the one that never leaves the ERP.

Plan a conversation