Why Doesn't My ETR in Tax Reporting Tie to FCCS?

EPM Tech Tips · Tax Reporting · 07

The effective tax rate in Oracle EPM Tax Reporting looks wrong, and when you trace it back, pre-tax income or the tax accounts don't match the consolidated numbers in Financial Consolidation and Close. The tax math is rarely the problem. Most of the time the two applications are looking at different data. The usual causes are a different point of view, a missing layer of the FCCS consolidation, a load that landed in the wrong place, or a Tax Reporting consolidation that hasn't run since the last load. Check them in the order below and you will usually find the gap before you open a single tax calculation.

Before you start

• Write down one failing number. Pick one entity, one period and one account (pre-tax income is the best start), and note the value in FCCS and the value in Tax Reporting. Work with that single difference until it is zero, then widen the scope.

• Pick your route. If pre-tax income itself doesn't tie, go through steps 1 to 5 in order. If pre-tax income ties but the ETR is still off, the gap is on the tax side: go to step 6.

Step 1 · Are you comparing the same number?

What happens. FCCS and Tax Reporting share most dimension names, so two forms can look identical while pointing at different members. A difference in view, entity level or currency produces a gap that no load or rule will ever fix.

How to check.

1. Put the FCCS value and the Tax Reporting value side by side in Smart View, one sheet per application, and set every dimension explicitly. Don't rely on form defaults.

2. Compare Scenario, Year, Period and View. Check that both retrievals use the same View member, periodic or year-to-date. Tax Reporting expects year-to-date data, so compare it with the FCCS year-to-date value.

3. Compare Entity (base or parent), Consolidation member (loads land in FCCS_Entity Input, so compare it with the matching FCCS member, not entity total or contribution), Currency (entity currency versus reporting currency), Multi-GAAP and Jurisdiction (loads default to TRCS_No Jurisdiction).

Fix. Align the two retrievals on every dimension. If the numbers tie once the POV matches, there is no data problem, only a reporting one.

Step 2 · Did the integration pull every FCCS layer?

What happens. Consolidated pre-tax income in FCCS is built from several layers: loaded data, journals, supplemental data, eliminations and adjustments. An integration that extracts only part of that stack, for example only the managed data source or only entity input, leaves journals or eliminations behind. The base numbers then tie, but the consolidated number doesn't.

How to check.

1. Open the integration that moves data from FCCS to Tax Reporting in Data Integration (Home › Application › Data Exchange).

2. Review the source filters for Data Source, Consolidation, Movement and Account. Note which members are extracted.

3. In FCCS, check whether journals or late adjustments were posted to the failing entity and period after the integration last ran.

Fix. Extend the source filters so they cover every layer the tax team needs, or agree explicitly that consolidation adjustments are handled inside Tax Reporting. Re-run the integration after the FCCS close is final, not before.

Step 3 · Did the load land where tax expects it?

What happens. Even with the right source data, the target mapping decides where it lands in Tax Reporting. A wrong period or year mapping, periodic data extracted where Tax Reporting expects year-to-date, or book data mapped to the wrong Movement or Data Source member will all change pre-tax income.

How to check.

1. In the integration, review the period mapping and confirm that source periods map to the right Tax Reporting period and FY-prefixed year.

2. Confirm the integration extracts the FCCS year-to-date view, not periodic data. For a Sparse View dimension, the dynamic YTD member is only exported with the All Data option. Periodic values, or a YTD member that isn't exported, won't match FCCS year-to-date.

3. Review the target mappings for Movement and Data Source. Book data should land on the members your tax automation reads, for example the movement member your tax automation rules use as their source, and a base member under FCCS_Data Input.

4. Open a book data form for the failing entity and use Drill Through on the pre-tax income cell to see the loaded source rows.

5. Check the process details for rejected or unmapped rows.

Fix. Correct the period, view or member mapping. Then clear only the book data you loaded (restrict the clear to the Data Source and Movement members the integration writes) and reload. Warning: a broad clear can also wipe manual tax adjustments and provision entries. Don't load on top of bad data.

Step 4 · Has Tax Reporting been consolidated since the load?

What happens. Loading data marks the affected entities as impacted. Tax automation, translation and the roll-up to parent entities only run when you consolidate. Until then, base entities can show the new book data while the tax accounts, the parents and the ETR still show the old results.

How to check.

1. From the Home page, open Forms › Data Status.

2. Set the scenario, year and period, and look at the status of the failing entity and every parent above it.

3. Any status other than OK means the stored results are out of date.

Fix. Select the parent entity's cell in Data Status and run Actions › Consolidate. You need write access to the parent entity to consolidate it. Consolidating a parent also consolidates its descendants and any impacted prior periods. Watch progress in the Jobs console. Use Force Consolidate only to recover from a process that was interrupted.

Step 5 · Do the exchange rates match?

What happens. Tax Reporting translates with its own rate tables. If those rates differ from the ones FCCS used, pre-tax income in the reporting currency won't tie, even when entity currency ties to the cent. Rate overrides and the weighted average rate option for pre-tax income (the NIBT accounts) can widen the gap.

How to check.

1. Compare the entity currency values first. If they tie and only the reporting currency differs, the problem is translation.

2. Open the FX rates forms in the Library and compare average and ending rates with the FCCS rates for the same period.

3. Check whether the application uses rate or amount overrides on pre-tax income, or the weighted average rate (WAR) forms, including NIBT FX Override WAR.

Fix. Load the same rates into both applications from one source, then consolidate again so translation reruns.

Step 6 · Is the tax side of the ETR complete?

When pre-tax income ties and the ETR still looks wrong, the issue is in the tax calculation. Check that the tax automation rules map every book account that should feed permanent or temporary differences. Run the Tax Automation Trace to see which source amounts reached which tax accounts. Confirm the statutory rates in Tax Rates, and for the consolidated reconciliation, the rates in Consolidated Tax Rates (Home › Application › Configuration). Then reopen the Consolidated ETR form after a fresh consolidation.

Quick checklist

1. Same POV in both applications · Smart View, one sheet per application

2. Every FCCS layer extracted · Integration source filters

3. Period, YTD view and member mapping · Integration mappings and Drill Through

4. Consolidated since the last load · Forms › Data Status

5. Same exchange rates · FX rates forms in the Library

6. Tax automation, rates and ETR · Tax Automation Trace, Tax Rates, Consolidated ETR

Pedro San Martín · Founder & Principal, Asher & Company