Let’s be clear. Automatic tax determination has its limits and implementation must account for exception handling. But in most cases technical constraints or poor design undermine automation. To evaluate changes to improve it, one can use tax engine’s frontend to do individual “what-if” simulations but this is not practical to test multiple hypotheses at scale.
Our Tax Simulation Module (TSM) addresses that by (re)determining the taxes using different variants of tax drivers data available in or outside of SAP. You can test changes in data (corrections), interface, engine configuration or tax content. TSM results can then be compared with actual G/L and tax reporting to support corrective actions.
But there is more to it.
Unique architecture
- Complete scope – we include missed transactions like intra-company assets and goods movements, or where no or incorrect tax code was used.
- More accurate – tax drivers may not be definite at posting time or data was not validated, or is just not available in SAP. We gather details from other sources for the most accurate tax determination.
- Overcome interface gaps – SAP tax interface has known gaps, new bugs are found regularly and customization is cumbersome. Our approach is transparent and consistent.
- BYOL – Bring Your Own License. We run on our platform many instances of your current tax engine(s) to quickly determine the tax and report on full responses.
Benefits
- Use as control – compare with SAP and tax engine records. Investigate mismatches and correct before filing.
- Goods/assets movements – we calculate use tax correctly, using the right tax base valuation and taking into account reciprocity agreements.
- Combine with TaxTract – use information on the invoice itself to calculate the tax.
- Intercompany transactions – SAP sends the clearing G/L account to the tax engine, we correctly send the offset lines.
- PO split – when a PO line is allocated to multiple G/L postings, SAP only sends the first one. We use all lines to determine partial exemptions.
- Engine implementation or migration – tax consultants can use TSM to test engine configuration holistically, not just scenarios.
- Location-to-Jurisdiction – tax jurisdiction codes rely on addresses, which are assumed to be correct. Cleansing master data does not help on one-time addresses or where there is no address on file. Also, ship-to address does not always equate place of taxation. Our approach is to use Open Location Codes to accurately mark places of taxation using geolocation hints found anywhere in the transaction data or retrieved indirectly e.g. from IoT or sensor logs. This can be a street address – which we pre-validate -, coordinates, IP address or public/internal place codes (e.g. IATA airport). We then determine within which jurisdictions’ boundaries the Open Location Code falls before calling the tax engine.
