E-Invoicing Was Born in Indirect Tax — and Why Its Future Belongs to Total Tax Governance

4 days ago
17 min read

Across conferences, boardrooms, tax events and transformation meetings, one question keeps coming up:

Is e-invoicing a Tax project, a Finance project or an IT project?

It is a fair question. But it is not the most important question. Even when people say e-invoicing is a “Tax project”, the word “Tax” is often interpreted through an old lens. The assumption is usually simple:

E-invoicing is transactional.VAT is transactional.Indirect Tax owns VAT. Therefore, e-invoicing belongs mainly to Indirect Tax.

That assumption is understandable.

Historically, it is also largely correct.

E-invoicing and clearance models became closely associated with VAT and GST because VAT/GST is an invoice-native, transaction-level tax. The invoice is not merely supporting evidence. It is the central artefact through which the tax result is created, validated, deducted, reported and challenged.

But that is only the beginning of the story.

The bigger shift is this:

E-invoicing was born in Indirect Tax because VAT lives inside the invoice. But its future belongs to total tax governance because the invoice is becoming the first machine-readable version of enterprise truth.

That is the strategic issue businesses need to understand.

1. Why E-Invoicing Has Always Been Closely Linked to Indirect Tax

The strongest reason is structural.

VAT and GST are transaction-level taxes.

Every taxable supply creates a tax consequence at the level of the transaction. The invoice captures the supplier, buyer, supply description, tax rate, taxable value, tax amount, timing, currency, place of supply indicators, tax category and credit note linkage.

In VAT/GST, the invoice does several things at once.

It evidences the supply. It supports the seller’s output tax. It supports the buyer’s input tax recovery. It captures the taxable value. It helps determine timing. It becomes the audit trail for the tax authority.

Direct tax does not work like that.

Corporate tax is usually calculated on a net profit basis over an accounting period. Revenue, expenses, depreciation, provisions, financing costs, tax adjustments, exemptions, disallowances, transfer pricing adjustments and losses all come together to determine taxable income.

No single invoice creates the corporate tax liability in the same way that an invoice can create a VAT or GST consequence.

That is why e-invoicing naturally attached itself to VAT/GST first.

The unit of taxation and the unit of control are the same: the transaction.

For direct tax, the invoice is important, but it is only one input into a broader computation.

That difference explains the historical linkage between e-invoicing and indirect tax.

2. Clearance Models Were Designed for a VAT/GST Problem

Clearance models did not become VAT/GST mechanisms by accident.

They were designed to solve a very specific VAT/GST control problem.

VAT systems contain an inbuilt vulnerability: the input tax credit mechanism.

One party charges VAT. The counterparty claims VAT. The tax authority must ensure that the seller’s output tax and the buyer’s input tax are consistent.

That creates a natural matching problem.

If the seller reports output VAT of AED 100,000 and the buyer claims input VAT of AED 100,000, the authority wants to know whether both sides are referring to the same underlying transaction.

This is why e-invoicing is so powerful for VAT/GST.

It allows the authority to compare:

supplier output tax,
buyer input tax,
invoice value,
tax rate,
tax category,
counterparty identity,
credit note adjustments,
timing,
payment trail,
and return reporting.

This is also why many continuous transaction control and clearance models around the world have been introduced as VAT/GST compliance mechanisms.

The scale of the problem is material. The European Commission estimated the EU VAT compliance gap for 2023 at approximately 9.5% of VAT Total Tax Liability, equal to around EUR 128 billion. That gap includes fraud, evasion, insolvency, errors and other non-compliance factors. Missing-trader and carousel fraud are among the best-known VAT fraud patterns because they exploit the time lag between invoice issuance, input tax recovery and authority detection.

Latin American clearance models, European digital reporting reforms, India’s GST e-invoicing architecture, Saudi Arabia’s FATOORAH programme and the UAE e-invoicing framework all reflect the same structural logic: where the tax depends heavily on invoice-level data, controlling invoice data becomes one of the most powerful ways to control the tax.

The policy logic is clear.

When a tax depends on invoices, controlling invoice data becomes a natural compliance strategy.

3. Why Direct Tax Was Not the Natural Starting Point

Direct tax has a different control problem.

Direct tax risks usually do not arise simply because an invoice exists.

They arise because of deeper questions:

Was the expense deductible? Was the revenue recognised correctly? Was the related-party charge arm’s length? Was the service actually received? Was the cost shareholder-related? Was the royalty commercially justified? Was the recharge a pass-through recovery or a taxable service fee? Was the transaction aligned with economic substance? Was the profit allocated to the right jurisdiction?

These questions cannot be resolved merely by clearing an invoice.

An invoice may prove that something was billed.

It does not prove that the direct tax treatment is correct.

For example, a UAE entity may invoice a foreign related party for “management support services”.

For VAT, the question may be whether the service is zero-rated, standard-rated, outside the scope, or subject to a particular place-of-supply rule.

For corporate tax, the question may be whether the revenue is correctly recognised, whether the cost base is properly allocated, and whether the income is attributable to the right entity.

For transfer pricing, the question may be whether the charge is arm’s length, whether the service was actually received, whether the benefit test is met, and whether the pricing is supported by benchmarking.

For Pillar Two, the question may be how the income, covered taxes, and jurisdictional allocation interact with GloBE calculations.

For CBCR, the question may be whether the revenue and profit allocation are consistent with the group’s country-by-country reporting profile.

The same invoice can be valid for VAT purposes and still raise direct tax questions.

This is why direct tax was not the natural starting point for e-invoicing.

Direct tax is not invoice-clearance native.

But that does not mean direct tax is unaffected.

It means the direct tax impact emerges at the analytics, reconciliation and defensibility layer.

That is where the world is now moving.

4. Tax Administration 3.0 Changes the Conversation

The OECD’s Tax Administration 3.0 framework is essential to understanding this shift.

The OECD released its foundational Tax Administration 3.0: The Digital Transformation of Tax Administration report in 2020. It later developed digital-transformation workstreams and e-invoicing specific analysis, including Tax Administration 3.0 and Electronic Invoicing, published in 2024. The direction is clear: modern tax administration is moving from periodic form submission toward embedded, data-driven, system-to-system tax administration.

Tax Administration 3.0 is not merely about digitising forms. It is about embedding tax processes into the natural systems that taxpayers already use to transact, account, pay, report and operate.

In practical terms, tax is moving from a separate reporting activity into the systems where business activity actually happens.

That is the deeper point.

E-invoicing is not only about replacing PDF invoices with XML.

It is one of the mechanisms through which tax moves from downstream reporting into upstream transaction systems.

This is where the historical indirect-tax story starts becoming a total-tax story.

Once invoice data becomes structured, standardised, machine-readable and visible close to the transaction event, it no longer remains only a VAT dataset.

It becomes a transaction-level data foundation for:

VAT,
Corporate Tax,
Transfer Pricing,
Pillar Two,
CBCR,
customs,
banking information exchange,
ERP reconciliation,
financial reporting,
sector analytics,
risk profiling,
audit selection,
taxpayer behaviour analysis,
and future AI-enabled tax administration.

That is the strategic shift.

E-invoicing is operated through indirect tax, but increasingly exploited for whole-of-tax intelligence.

5. The UAE Model Makes This Shift Visible

The UAE e-invoicing framework illustrates this transformation clearly.

Ministerial Decision No. 243 of 2025 establishes the scope, definitions, obligations and governance framework for the UAE Electronic Invoicing System. Ministerial Decision No. 244 of 2025 sets the implementation timeline: pilot and voluntary implementation from 1 July 2026, mandatory implementation for persons with revenue equal to or exceeding AED 50 million by 1 January 2027, mandatory implementation for persons with revenue below AED 50 million by 1 July 2027, and mandatory implementation for Government Entities by 1 October 2027.

The UAE has adopted a Peppol-based 5-corner model involving:

the supplier,
the supplier’s Accredited Service Provider,
the buyer’s Accredited Service Provider,
the buyer,
and the Federal Tax Authority.

The framework is still deeply connected to VAT mechanics. It uses concepts such as tax invoices, electronic credit notes, tax data, invoice categories, tax codes, mandatory fields, transaction type indicators and structured invoice data.

But the architecture is broader than a traditional VAT return process.

It is a structured transaction visibility environment.

The UAE framework does not merely ask the taxpayer to file a return after the period-end. It creates a system through which invoice and credit note data move through a regulated exchange ecosystem, with tax data reported as part of that exchange environment.

That matters because structured transaction data does not remain confined to one tax type forever.

Once the authority receives structured invoice-level data, the same data can become relevant to wider tax administration, analytics, comparison and audit activity.

This does not mean every direct tax, Pillar Two, CBCR or transfer pricing consequence is formally governed by e-invoicing legislation.

Regulation is silent on many of those operating model implications.

The discussion below is therefore Implementation Guidance derived from industry practice and aligned with the direction of Tax Administration 3.0 and UAE regulatory intent.

The practical message is clear:

The e-invoice may begin as an indirect tax data object, but it becomes part of a wider tax evidence environment.

6. Peppol, PINT-AE and the Rise of Semantic Tax Data

The UAE e-invoicing framework also uses the Peppol and PINT-AE architecture.

Peppol provides the interoperability framework. It allows different parties, systems and service providers to exchange structured business documents through a common network architecture.

PINT-AE localises that international structure for the UAE. It allows the UAE to preserve local legal, tax and reporting requirements while participating in a broader interoperability ecosystem.

This is important because e-invoicing is not only transmission.

It is semantic standardisation.

The invoice must not only move. It must mean the right thing. It must carry structured meaning that systems, ASPs, buyers, suppliers and tax authorities can interpret consistently.

This is where businesses need to move beyond the old question of “Can we generate XML?”

The better question is:

Can our enterprise describe every material transaction in a tax-sensitive, machine-readable, cross-tax-consistent way?

That is a much harder question.

7. Tax Velocity Gap: The Real Safety Net That Is Disappearing

From T+n Visibility to T+0 Visibility

To understand why e-invoicing changes the tax operating model, we need to define the Tax Velocity Gap precisely.

The Tax Velocity Gap is not simply the time between transaction creation, accounting recognition, tax review and tax filing. Those are internal taxpayer processes affected by the gap.

The Tax Velocity Gap is the time difference between two events:

the transaction occurring and the transaction becoming visible to the tax authority.

In the traditional world of Tax Administration 1.0 and Tax Administration 2.0, this gap was T+n.

The “n” could be 30 days, 90 days, several months or even more, depending on the tax.

A VAT transaction might become visible through a monthly or quarterly return. A corporate tax position might become visible only through an annual corporate tax return. Transfer pricing, CBCR and Pillar Two positions could emerge even later through documentation, disclosures and global reporting cycles.

That delay was not just administrative timing.

It was the taxpayer’s hidden safety net.

It gave organisations time to reconcile ERP data, review tax codes, correct mistakes, align finance records, prepare tax positions, document transfer pricing logic, and ensure that the story reported to the authority was coherent.

Tax Administration 3.0 changes this sequence.

With e-invoicing, real-time reporting and structured transaction data exchange, the authority’s visibility moves closer to the transaction itself. The Tax Velocity Gap compresses from T+n to T+0.

This creates a profound operating model challenge.

Tax returns may still be filed at T+n. Corporate tax returns, Pillar Two submissions, CBCR filings and transfer pricing documentation may still be prepared after the period-end.

But the transaction-level data underpinning those filings may already have been reported, exchanged or made visible at T+0.

That means the tax return is no longer the first structured tax story the authority sees.

The authority may already have seen the transaction stream.

The taxpayer’s future challenge is therefore not only to file correct returns.

It is to ensure that every T+n submission is reconcilable with the T+0 data already visible to the authority.

This is the heart of the transformation.

In the old world, tax returns told the authority what happened. In the new world, e-invoicing and real-time data already show the authority what happened — tax returns must now reconcile to that reality.

8. The New Operating Model Problem: Tools Are Necessary, But Not Sufficient

This is where many organisations are underestimating the change.

They are trying to manage a way-of-working shift with tools.

They are buying middleware, dashboards, ASP solutions, connectors, validation engines and reconciliation reports. Those tools are necessary. No serious e-invoicing implementation can function without technology.

But the core problem is not only technological.

It is operational.

It is behavioural.

It is interpretive.

It is governance-driven.

A tool can move data. A tool can validate fields. A tool can generate dashboards. A tool can flag mismatches. A tool can route invoices. A tool can create XML. A tool can show transmission status.

But a tool cannot decide the tax interpretation.

A tool cannot own the divergence between indirect tax and direct tax.

A tool cannot approve the policy logic behind a VAT code.

A tool cannot explain why the same transaction appears differently in VAT, corporate tax, transfer pricing, Pillar Two and CBCR.

A tool cannot defend the taxpayer when the authority’s mirror view raises questions.

That requires a new operating model.

It requires tax governance to move upstream, before the transaction becomes visible at T+0.

This is why e-invoicing is not merely an indirect tax implementation.

It is the first visible pressure point in a much larger shift toward real-time, cross-tax, authority-visible enterprise governance.

9. Interpretive Divergence: The Same Transaction, Different Tax Worlds

One Economic Event, Multiple Tax Interpretations

When the Tax Velocity Gap collapses, interpretive divergence becomes visible.

Interpretive Divergence occurs when the same transaction is interpreted differently across different tax, accounting or regulatory lenses.

This is not always because someone made a mistake.

Sometimes the divergence exists because different tax regimes ask different questions.

Take a management fee charged by a UAE entity to a foreign related party.

Indirect Tax may ask:

Is the supply standard-rated, zero-rated or outside scope?

Corporate Tax may ask:

Is the revenue correctly recognised and taxable in the UAE?

Transfer Pricing may ask:

Is the charge arm’s length and supported by benchmarking?

Pillar Two may ask:

How does this income affect jurisdictional GloBE income and covered taxes?

CBCR may ask:

Which jurisdiction reports the revenue, profit and employees connected to the activity?

Banking data may show:

Was the payment actually made, delayed, split, netted or settled through an intercompany account?

ERP may show:

Was the transaction posted to the right entity, GL account, profit centre and tax code?

E-invoicing may show:

What did the structured invoice say at the moment it was transmitted?

Each layer sees the same economic event differently.

Historically, these interpretations lived in separate files, systems and reporting cycles.

Indirect Tax had VAT returns. Direct Tax had corporate tax returns. Transfer Pricing had local files and master files. Finance had ERP and financial statements. Treasury had bank records. Global tax had CBCR. Pillar Two teams had GloBE data packs.

E-invoicing starts pulling these worlds closer together.

The authority may not need to wait for a full audit file.

It can begin with the structured transaction pattern.

This is the power of the Authority Mirror View.

10. Authority Mirror View: What the Authority Sees First

The Authority Mirror View is the structured data picture of the taxpayer that the tax authority sees through real-time or near-real-time data channels.

This is not theoretical. Modern tax administrations increasingly use invoice data, return data, payroll data, customs data, financial statements and other third-party information to create risk profiles, identify inconsistencies and select cases for review. OECD tax administration material increasingly describes this movement toward broader, real-time or near-real-time enterprise visibility. The exact tools and data combinations differ by jurisdiction, but the direction is consistent: tax authorities are moving from isolated return review toward connected data analytics.

In the old model, the taxpayer usually saw the problem first.

In the new model, the authority may see the pattern first.

A taxpayer may think:

“We have filed our VAT return correctly.”

But the authority may ask:

Why do e-invoicing transmissions show a different revenue base?

Why do credit notes not reconcile to earlier invoices?

Why do zero-rated supplies appear inconsistent with buyer location, customs data or export evidence?

Why do intercompany charges reported in e-invoicing not align with transfer pricing disclosures?

Why do VAT returns, corporate tax returns, CBCR and financial statements tell slightly different stories?

Why does banking data suggest transaction settlement patterns inconsistent with invoice timing?

Why does third-party information exchange show a transaction pattern that the taxpayer’s return does not explain?

This is where the old siloed tax model breaks.

The question is no longer:

Did each tax team file its own return?

The new question is:

Can every representation of the same economic reality reconcile across every tax, finance, ERP and third-party data ecosystem?

That is a fundamentally different standard.

11. The New Reconciliation Chain

Reconciling T+0 Transaction Data to T+n Tax Submissions

Regulation is silent on a single enterprise-wide reconciliation architecture linking indirect tax, direct tax, Pillar Two, CBCR, transfer pricing, ERP, e-invoicing transmissions and third-party data.

The following is Implementation Guidance derived from industry practice and aligned with the direction of digital tax administration.

Future-ready tax governance should increasingly build a reconciliation chain that looks like this:

Indirect Tax Returns reconciled to → Corporate Tax Returns reconciled to →Pillar Two Submissions reconciled to → CBCR Filings reconciled to → Transfer Pricing Master File and Local Files reconciled to → ERP Transaction Ledger reconciled to → E-Invoicing Transmissions reconciled to → Banking and Third-Party Transaction Data reconciled to → Authority Mirror View

This is not a theoretical compliance dream. It is where tax governance is heading.

The taxpayer must be able to explain why its systems are trustworthy.

That explanation will not come from one tax return.

It will come from data lineage, reconciliation, governance, controls and Tax-as-Code.

12. Tax-as-Code: Governing Divergence Before It Becomes a Dispute

Turning Interpretation into Governed System Logic

Tax-as-Code is often misunderstood.

It does not simply mean automating tax rules in ERP.

It means translating tax interpretation into governed, executable, version-controlled logic.

In a real-time tax environment, Tax-as-Code should answer:

What tax rule was applied?

Which transaction category triggered it?

Which ERP field drove the treatment?

Which tax code was selected?

Which legal interpretation supports it?

Which evidence is required?

Who approved the logic?

When was the logic changed?

Was the change tested?

Does the same logic align across VAT, Corporate Tax, Transfer Pricing, Pillar Two and CBCR?

Tax-as-Code becomes the governance bridge between interpretation and execution.

It does not eliminate interpretive divergence.

It governs it.

That distinction is important.

Some transactions will legitimately have different treatments across different taxes.

A transaction may be zero-rated for VAT but still taxable for Corporate Tax.

A recharge may be outside the scope of VAT in one context but still relevant for transfer pricing.

A timing difference may be acceptable for accounting but require explanation for tax.

The issue is not that all tax treatments must be identical.

The issue is that all differences must be intentional, documented, explainable and reconcilable.

Tax-as-Code helps create that defensibility.

It converts silent assumptions into visible logic.

13. Defensibility in the Authority Mirror World

The future tax defence will not only ask:

“Was the law applied correctly?”

It will also ask:

“Can the taxpayer demonstrate that the system consistently applied the approved interpretation before the transaction became visible to the authority?”

That is a different burden.

A defensible tax position in a real-time environment needs more than a technical memo.

It needs:

documented interpretation,
approved tax logic,
mapped ERP fields,
governed master data,
tested transaction scenarios,
version-controlled rules,
exception handling,
reconciliation evidence,
ownership records,
and audit-ready data lineage.

This is where Tax-as-Code supports the taxpayer.

When the authority mirror view raises a question, the taxpayer must be able to show:

This is the transaction type. This is the rule applied. This is the system logic. This is the evidence condition. This is the approving owner. This is the reconciliation trail. This is why the VAT treatment differs from the Corporate Tax treatment. This is why the transfer pricing file describes the transaction this way. This is how the Pillar Two data pack reconciles. This is how the CBCR position aligns. This is how the ERP ledger ties back to the e-invoicing transmission.

That is future tax defensibility.

Not narrative after the fact.

Governance before the transaction leaves the building.

14. What Breaks in Real Life

The biggest failures will not come from standard invoices.

Standard invoices will usually pass.

What breaks are the transactions that carry interpretive complexity.

Examples include:

intercompany management fees,
cross-border service charges,
free zone supplies,
mixed supplies,
continuous supplies,
advance payments,
credit notes,
recharges and disbursements,
loyalty redemptions,
principal-agent structures,
related-party royalties,
cost allocations,
margin scheme supplies,
reverse charge scenarios,
contract variations,
netting arrangements,
multi-entity settlements,
branch and head office flows.

These are not just VAT issues.

They are total tax governance issues.

A credit note may correct output VAT, but also alter revenue recognition.

A recharge may be standard-rated for VAT, but disallowed or recharacterised for corporate tax.

A related-party service invoice may pass e-invoicing validation, but fail transfer pricing defensibility.

A zero-rated export invoice may look fine in the e-invoicing transmission, but later fail evidence testing.

A cross-border payment may reconcile in banking systems, but not align with invoice timing or intercompany balances.

A Pillar Two data pack may use accounting data that does not reconcile cleanly to invoice-level revenue.

A CBCR filing may classify revenue in a way that conflicts with ERP entity-level reporting.

In the old world, these differences could often be explained later.

In the new world, the authority may see the inconsistency before the taxpayer has prepared the explanation.

That is the problem.

15. Why the Green Dashboard Is Not Enough

A green dashboard may mean that the invoice transmitted successfully.

It may mean that mandatory fields were populated.

It may mean that XML validation passed.

It may mean that the ASP exchange worked.

But it does not necessarily mean that the tax treatment is correct.

This is the Green Dashboard Paradox.

A transaction can be technically accepted but semantically wrong.

It can move through the system while carrying the wrong economic meaning.

That distinction matters.

Syntax asks:

Can the system read the invoice?

Semantics asks:

Does the invoice mean the right thing?

Tax governance must cover both.

A business that solves syntax but ignores semantics has implemented e-invoicing technically but not defensibly.

16. From Indirect Tax Project to Total Tax Governance Model

This is why the traditional ownership question is no longer enough.

E-invoicing is legally and operationally anchored in tax.

It is first felt by Indirect Tax.

It is executed through Finance, ERP, IT, ASPs and data teams.

It is increasingly relevant to Direct Tax, Transfer Pricing, Pillar Two, CBCR and audit.

It is governed through enterprise data architecture.

So the better question is not:

Is e-invoicing a Tax, Finance or IT project?

The better question is: Can the organisation govern tax-sensitive transaction data at the speed at which the system now creates, exchanges, validates and reports it?

That question changes the conversation.

It moves the discussion from project ownership to enterprise accountability.

17. The Future Tax Profile: Fusion Professionals

This is why the future belongs to Fusion Tax Professionals.

The future tax professional cannot be only:

a VAT return reviewer,
a corporate tax return preparer,
a transfer pricing documentation specialist,
an ERP configurator,
a finance reconciler,
or an IT project participant.

Those skills remain important.

But they are no longer enough.

The new tax profile must connect:

tax law,
indirect tax,
corporate tax,
transfer pricing,
Pillar Two,
CBCR,
ERP logic,
e-invoicing transmissions,
Peppol and PINT-AE data structures,
master data governance,
Tax-as-Code,
continuous controls,
Authority Mirror View,
banking data,
third-party reporting channels,
AI-driven analytics,
and audit defensibility.

That is the Fusion Tax Professional.

This person does not replace specialists.

This person connects specialists.

They understand that the invoice is not merely a VAT document.

They understand that ERP is not merely an accounting system.

They understand that tax codes are not merely configuration values.

They understand that master data is not merely administrative hygiene.

They understand that a green dashboard is not proof of correctness.

They understand that authority visibility is moving faster than traditional tax governance.

That is the professional profile required for Tax Administration 3.0.

18. The Strategic Takeaway

E-invoicing is closely linked to indirect tax because VAT and GST are invoice-native taxes.

That historical linkage is correct.

But it is no longer sufficient.

The real transformation is that structured invoice data is becoming the foundation layer of digital tax administration.

The invoice is now:

a VAT evidence object,
a corporate tax data point,
a transfer pricing signal,
a Pillar Two input,
a CBCR reconciliation marker,
an ERP control point,
a banking data comparator,
a third-party information exchange node,
and an authority-facing transaction assertion.

That is why e-invoicing must be understood through a broader lens.

It begins with Indirect Tax.

It expands into Direct Tax.

It converges with Transfer Pricing.

It feeds Pillar Two and CBCR consistency.

It depends on ERP and master data.

It is tested through authority analytics.

It is defended through Tax-as-Code.

And it is governed by Fusion Professionals.

The world has moved from forms to data. From periodic reporting to real-time visibility.From tax returns to transaction streams.From siloed compliance to total tax governance.

What's Next?

This operating model shift is not theoretical. It is already here.

If you are implementing e-invoicing, you need to audit three things:

Operating Model Readiness — Is your Indirect Tax, Direct Tax, Transfer Pricing, Finance, ERP and Data team aligned on how the same transaction will be coded, reported, reconciled and defended?
Tax Velocity Gap — Have you built governance controls that are fast enough to manage T+0 authority visibility while tax teams are still used to working at T+n?
Fusion Capability — Do you have professionals who can connect tax law, ERP logic, regulatory requirements, data lineage, reconciliation architecture and Authority Mirror View analytics in real time?

We have built a practical operating model checklist that maps these three dimensions to your e-invoicing implementation.

It takes a few weeks to self-assess where your organization stands — and often surfaces the gap between technical e-invoicing readiness and governance-model readiness.