End-to-end process · Insurance premium tax (IPT)

Premium-to-Tax

From the insurance premium to the paid tax return: how process intelligence exposes skipped controls, wrong sequences, rework and open tax obligations in insurance premium tax.

Jump to the findingsRead the full case

What is Premium-to-Tax?

Premium-to-Tax is the end-to-end process from a tax-relevant insurance premium transaction to the settled insurance premium tax (IPT). Every transaction has to be recognised as taxable, assigned to the right jurisdiction, calculated correctly, posted to the general ledger and reconciled before it flows into a tax return that is reviewed, approved, filed and paid. From a bird’s-eye view it sounds simple – in reality a single case passes through operational insurance data, tax determination, accounting, reconciliation and tax reporting.

Note: the dataset shown is a synthetic demonstration dataset with deliberately built-in, realistic deviations. The figures illustrate analysis paths and are not production figures of any customer.

At a glance

11

Core activities

from premium transaction to tax payment, each backed by its own source object

6

Deviation patterns

skips, wrong order, rework and abandonment – each with its own compliance question

≈ 5%

Risk location skipped

tax determination without prior determination of the risk location – and so the jurisdiction

≈ 3%

Filed before approval

tax returns reach the authority before the internal control is complete

The process in four phases

The intended flow is a clear sequence of eleven activities with realistic waiting times in between. A case is only complete once the tax return has been filed and paid – everything in between is a control point that process mining can make visible.

Phase 1

Capture & tax determination: from premium to tax amount

A premium transaction – new or renewal premium, adjustment, cancellation or refund – is captured. The location of the insured risk is then determined, the tax treatment (tax type, jurisdiction, tax code, rate) is derived from centrally maintained tax rules, and the tax amount is calculated. Two to four hours typically pass between steps.

Business objects

  • PREMIUM_TRANSACTION
  • RISK_LOCATION
  • TAX_DETERMINATION
  • TAX_RULE
  • TAX_CALCULATION
  1. Capture premium transaction
  2. Determine risk location
  3. Perform tax determination
  4. Calculate tax amount

Guiding question

Was the risk location – and so the right jurisdiction – determined before the tax determination?

Phase 2

Accounting & reconciliation: the central control point

The tax amount is posted to the general ledger with GL account, company code and document reference. The calculated tax is then reconciled against the posting – differences may raise a tax exception. About 24 hours typically pass between reconciliation and the tax return.

Business objects

  • GL_POSTING
  • TAX_RECONCILIATION
  • TAX_EXCEPTION
  1. Post tax to general ledger
  2. Reconcile tax amounts

Guiding question

Do calculation and posting match – and how often does reconciliation trigger a recalculation?

Phase 3

Tax return & approval: from transaction to return

The tax return is prepared per legal entity, tax type, jurisdiction and reporting period; individual calculations are assigned to it as tax return items. Before external filing, tax experts or managers review and approve the return – a key internal compliance control.

Business objects

  • TAX_RETURN
  • TAX_RETURN_ITEM
  • TAX_APPROVAL
  • LEGAL_ENTITY
  • USER_ORG
  1. Prepare tax return
  2. Prepare tax return item
  3. Review and approve tax return

Guiding question

Does every reconciled transaction reach a return – and is that return approved before filing?

Phase 4

Filing & payment: reporting and payment obligation

After approval the return is filed with the competent tax authority, with an authority reference and confirmation. The final step is paying the tax liability; about 48 hours typically pass between filing and payment.

Business objects

  • TAX_FILING
  • TAX_PAYMENT
  1. File tax return
  2. Execute tax payment

Guiding question

Was every filed tax return actually paid?

Every business object carries its own created_at timestamp; these timestamps are used to reconstruct the actual flow. Because objects and relationships are kept in the event knowledge graph, every deviation can be traced back to the individual transaction, calculation or return.

Supporting data objects

Besides the operational activities, the model contains context objects that are not mandatory happy-path steps. They make it possible to ask not only what happened – but who was involved, which rule applied and which exception was raised.

POLICY
The underlying insurance contract that links transactions and risk information to the insurance business.
LEGAL_ENTITY
The reporting company or company code responsible for the transaction and the tax return.
TAX_RULE
The tax rules used in determination, with jurisdiction, tax type, rate and rule version.
USER_ORG
Employees, roles and teams – for responsibilities, exception handling and approvals.
TAX_EXCEPTION
Tax processing exceptions linked to faulty calculations, reconciliation differences or missing information.

Six deviations from the expected process

The interesting insights lie less in the happy path than in the deviations from it. The central question is: how does the process actually run compared to the expected one – and which deviations create compliance or operational risk?

Finding 1 · Skip

The risk location is never determined

The expected flow is premium transaction → risk location → tax determination. In about 5% of cases the middle step is missing and the process jumps straight to tax determination.

For insurance premium tax, the location of the insured risk can decide which jurisdiction may levy the tax. Without it, the case risks the wrong jurisdiction, the wrong rate, the wrong tax treatment – or simply insufficient evidence for the tax decision.

≈ 5%

of cases go straight from the premium transaction to tax determination

Instead of “Was the tax determined?”

the analysis asks: “How many transactions get a tax determination without a prior risk-location determination?”

Finding 2 · Wrong order

Tax returns are filed before approval

Both activities happen – but in the wrong order: the return goes to the authority and the approval only follows afterwards.

Approval is an important internal control. Filing before it means information is sent externally before the review is complete – with the risk of unauthorised or incorrect returns, additional corrections and compliance findings. Checking whether activities happened is therefore not enough: the order matters too.

≈ 3%

of returns are filed before they are reviewed and approved

Instead of “Was the return approved?”

the analysis asks: “Was it approved before it was filed?”

Tax return process graph: path from “Prepare tax return item” straight to “File tax return” (150 cases, 3%) and a back arrow from “File tax return” to “Review and approve tax return”
Filing before approval: some cases jump from the item straight to “File tax return” and are only reviewed afterwards.

Finding 3 · Rework

Reconciliation triggers a new tax calculation

Reconciliation finds a problem and the tax calculation is run again. Possible causes: wrong tax rate, wrong tax base or jurisdiction, a difference to the GL posting, an outdated tax rule or incomplete source information.

This is probably one of the most important operational inefficiencies in the process: extra processing time, manual investigation, repeated calculations, additional accounting effort and potentially a delayed filing.

≈ 2%

of cases jump back to tax calculation after posting and reconciliation

Instead of “Has the tax been calculated?”

the analysis asks: “Which jurisdictions or tax types cause the most calculation rework – and how much time does it cost?”

Tax calculation process graph: back arrow from “Post tax to general ledger” to “Calculate tax amount” (19 cases, 2%) before “Reconcile tax amounts”
Rework after reconciliation: loops from the GL posting back to a new tax calculation.

Finding 4 · Rework

Returns are sent back for correction during approval

The reviewer spots a problem with the content of the return and sends it back for correction – for example missing or wrongly included transactions, wrong amounts, the wrong reporting period or the wrong jurisdiction.

Late rework is usually more expensive than catching a problem earlier, and it pushes the process closer to the statutory filing deadline.

≈ 5%

of returns are sent back in review and prepared again

Instead of “Was the return approved?”

the analysis asks: “Which teams or jurisdictions have the highest approval rework rates – and how much lead time does that cost?”

Approval process graph: loop between “Review and approve tax return” and “File tax return” with rework paths highlighted in red
Approval rework: returns loop back out of review before they can be filed.

Finding 5 · Abandonment

Reconciled transactions never reach a tax return

The transaction is processed and reconciled – but no tax return is created afterwards. It is effectively lost between operational tax processing and tax reporting.

Possible consequences: unreported taxable transactions, incomplete returns, understated tax liabilities and missed reporting obligations. A classic incomplete process case.

≈ 2%

of cases end right after reconciliation

Instead of “Is the transaction reconciled?”

the analysis asks: “Which reconciled transactions never reach the creation of a tax return?”

Process graph: cases end after “Reconcile tax amounts”; the next step “Prepare tax return” is only dashed and never reached
Abandonment after reconciliation: these cases never reach “Prepare tax return”.

Finding 6 · Abandonment

Filed, but never paid

The return is with the authority, but the process ends before payment is executed. The reporting obligation may be met while the financial obligation stays open.

This is a particularly important compliance risk: overdue tax liabilities, interest, penalties, payment reminders and extra manual investigation. It translates into a very clear control – filed but unpaid tax returns.

≈ 2%

of returns end after filing without a tax payment

Instead of “Was it filed?”

the analysis asks: “Which filed tax returns have no matching tax payment?”

Process graph: after “File tax return” only a dashed path leads to “Execute tax payment” and the process end – payment is not reached
Filed but not paid: after “File tax return”, “Execute tax payment” is never reached.

Questions the analysis answers

The dataset lets the analysis go beyond simply visualising the happy path.

  • What share of cases follows the expected process, and which variants occur most often?
  • Where are mandatory activities skipped, and which occur in the wrong order?
  • How often does rework occur, and how much extra lead time does it create?
  • Where do cases end prematurely?
  • Which jurisdictions, legal entities, transaction types or tax types have the highest deviation rates?
  • Which cases were filed without prior approval, and which filed returns were not paid?
  • Which transactions reached tax determination without a documented risk-location determination?
  • Where are the largest reconciliation differences, and which parts of the process cause the longest waits?

From “Was it filed?” to “How did we get there?”

Compliance

Identify skipped controls, wrong sequences, missing approvals and incomplete tax obligations.

Efficiency

Uncover rework loops, bottlenecks, unnecessary repetitions and long waiting times.

Transparency

Connect transaction-level tax processing, accounting, reporting, approval, filing and payment into one end-to-end view.

Frequently asked questions about Premium-to-Tax

What is a Premium-to-Tax process?

Premium-to-Tax is the end-to-end process from a tax-relevant insurance premium transaction to the paid insurance premium tax. It comprises eleven core activities: capture premium transaction, determine risk location, tax determination, tax calculation, GL posting, reconciliation, preparation of the tax return and return items, review and approval, filing and tax payment.

Why does the risk location matter so much for insurance premium tax?

The location of the insured risk can decide which country or jurisdiction has the right to levy insurance premium tax. If it is not determined, jurisdiction, tax rate and tax treatment may be wrong – and the evidence for the tax decision is missing.

Which deviations does the analysis reveal in the Premium-to-Tax process?

Six patterns: the risk-location determination is skipped (about 5%), returns are filed before approval (about 3%), reconciliation triggers a new tax calculation (about 2%), returns are sent back for correction during approval (about 5%), reconciled transactions never reach a return (about 2%) and filed returns are not paid (about 2%).

Why is it not enough to check whether a tax return was filed?

Because a filing says nothing about how it came about. Process mining shows whether approval came before filing, whether controls such as the risk-location determination were skipped, where work had to be repeated and whether the filing was actually followed by payment.

Are the figures from a real insurer?

No. The dataset is synthetic and contains deliberately built-in, realistic deviations. The figures illustrate analysis paths and are not production figures of any customer.

The full case description

All eleven process steps with source tables and typical waiting times, the supporting data objects and the six deviations in detail – step by step in the Noreja Help Center (in German).

Read the case in the Help Center

Want to analyse your own process? Talk to us.

Ready to Start

Understand your end-to-end process causally — talk to us

Join companies that are redefining growth and efficiency with intelligent process analysis.

Book a Demo