FOCUS 1.4 Changes Cloud Billing Data Again: How to Migrate Without Breaking Chargeback

Consider a late-2026 migration decision: a finance and engineering team has a hard deadline to update its multi-cloud billing pipeline to FOCUS 1.4 by the end of Q3, without disrupting chargeback, invoice reconciliation, or dashboards. The risk is not abstract. A compatible-looking schema change can break automated reports, misallocate costs, and undermine executive trust. This guide is for FinOps engineers and cloud data teams implementing the migration now. It follows the pipeline from raw exports to finalized reports and uses SQL transformations, validation rules, and acceptance tests to keep business-unit totals accurate. By the end, you will have a practical plan to adopt FOCUS 1.4 while preserving financial controls. For broader role context, Refonte Learning’s FinOps Specialist Career Path explains how this responsibility fits into FinOps work.

1. Why FOCUS 1.4 Is a Financial-Control Migration

Migrations of billing schemas are not just technical tasks: they are financial-control projects. The official FOCUS 1.4 specification was ratified on June 4, 2026 and adds datasets and fields explicitly to strengthen cost governance and invoice alignment. Its release caters to scenarios where procurement, finance, and engineering must all agree on the numbers, such as reconciling a cloud invoice against usage or allocating costs against budgets. This reflects FinOps maturity: 98% of organizations now manage AI spend, up from 31% two years earlier, broadening FinOps scope across technology. In this landscape, unified, auditable cost data is essential. The FinOps Foundation’s State of FinOps 2026 says practitioners seek consistent, unified cost and usage data across an increasingly complex technology landscape, and that FOCUS adoption is rising to meet that need.

Key cost-governance practices, including budget tracking, executive reporting, and chargeback, hinge on data integrity. The migration plan must do more than update code; it must preserve those controls. If a dashboard sums by business unit, or an automated report ties usage to invoice items, even a small column removal can throw off totals. Think like a financial auditor: “Did the chargeback logic allocate the same dollars as before, just in new columns?” This guide assumes AWS and Azure billing in a multi-cloud pipeline built on FOCUS 1.3 exports. Run the old and new pipelines side by side, and cut over only after chargeback and reconciliation tests pass. Treating the work as a FinOps project, rather than a routine technical update, creates clear accountability. Refonte Learning’s FinOps Practices for Cloud Cost Optimization provides broader cost-governance context.

2. Read the 1.4 Change Set Before Touching Pipelines

Before any code changes, read the official FOCUS changelog from end to end. FOCUS 1.4 is a mature, finance-driven release: it adds two new datasets, 47 new columns, 6 new attributes, and 2 new supported features. Specifically, FOCUS 1.4 introduces full InvoiceDetail and BillingPeriod datasets. InvoiceDetail has 22 new fields, including InvoiceId and PaymentDueDate, while BillingPeriod has 6 fields covering period boundaries and status. The ContractCommitment dataset also expands from 13 to 30 columns, adding sections for eligibility, lifecycle, and cost. In short, contracts and invoices become more granular.

At the same time, understand what changed in place. The changelog reports zero incompatible changes, meaning no existing field was renamed in a formally non-backward-compatible way. However, several migration-relevant changes still require code updates:

•     ContractApplied JSON: The format moves to a strict JSON Object Schema. Any SQL or parser that drills into the old ContractApplied blob must be updated to the new structure.

•     Removed fields: The old ProviderName and PublisherName columns are dropped; their roles were replaced by ServiceProviderName, HostProviderName, and InvoiceIssuerName. If any queries still reference the legacy columns, switch them to the new ones.

•     Attributes removed: The attributes ColumnHandling, DiscountHandling, and InvoiceHandling are removed (their logic moves to other sections). This affects how we interpret data completeness and corrections. For instance, the new spec explicitly defines a Dataset Completeness attribute, meaning every native column should be present unless a documented exception exists. We’ll need to audit each attribute change.

Migration rule: assume “migration-compatible changes” need code fixes, while “incompatible changes” would break pipelines. Thankfully, FOCUS 1.4 lists no incompatible changes. Still, consider this a backwards-incompatible upgrade until proven otherwise: test everything.

The migration-relevant highlights are:

•     Datasets: Added BillingPeriod, InvoiceDetail.

•     Columns (+47): New fields like PaymentDueDate, CommitmentProgramEligibilityDetails, BillingPeriodStart/End, etc..

•     Changed columns: e.g. ContractApplied now formal JSON, ProviderName removed.

•     Removed columns (2): ProviderName, PublisherName.

•     New features: Adds Invoice Reconciliation, Commitment Program Eligibility Details (we will use these).

•     Attributes: Adds things like DatasetCompleteness and DeliveryHandling, removes old handling attributes.

Keep the changelog handy when updating code. At minimum, update any transformation logic that parses ContractApplied, and drop or replace any fields slated for removal.

3. Map Every Current Export and Provider Extension

This is a multi-cloud pipeline, so inventory each data source and its schema. For AWS, use the native Cost and Usage Report (CUR) export to FOCUS. AWS’s FOCUS 1.0 with AWS columns documentation describes the FOCUS_1_0_AWS table, which follows the FOCUS 1.0 schema and adds five proprietary columns: x_CostCategories, x_Discounts, x_Operation, x_ServiceCode, and x_UsageType. These extensions may support analytics such as splitting cost by operation type, so preserve them. Do not overwrite them as if they were standard fields; treat them as provider metadata. For example, retain documented lineage if you alias x_UsageType as aws_x_UsageType in the conformed layer. Section 8 covers the extension boundary in detail.

For Azure, Microsoft Learn’s guidance on Cost Management exports explains that exports support the FOCUS format and allow users to select the schema version. Azure’s FOCUS export combines actual and amortized costs in one dataset, and the portal can use the latest or an earlier dataset schema. In practice, the pipeline must handle both states during migration: configure FOCUS 1.4 for the new path, retain the previous version for rollback, and confirm that every expected field still arrives. Key joins and mappings should be driven by stable identifiers such as InvoiceId and revised only when the selected Azure schema requires it.

If other clouds (e.g. GCP) or third-party tools feed into this pipeline, document their formats too. The goal is a “schema map” with one row per provider: which FOCUS version they emit, and which extra columns are present. We can tabulate it:

Understanding each source ensures no data is “dropped off” by the migration. Once documented, ensure your ETL layer ingests each format correctly. You might write a validator query like “SELECT COUNT(*) WHERE x_Operation IS NULL” on AWS export to check if those fields arrive as expected after the upgrade.

For broader provider context, see Multi-Cloud vs Hybrid Cloud Strategies. This migration is specifically a multi-cloud data-normalization problem that requires consistent cost semantics across sources.

4. Create a Versioned Billing Data Contract

Treat the billing schema as a formal contract. We will explicitly version our data layers so nothing breaks unexpectedly. Define layers: raw, conformed, semantic, and reporting. Each has its own contract:

•     Raw layer: ingest of each provider’s export (AWS, Azure, etc.) as-is. Here the contract is “we will collect these columns exactly as emitted, plus metadata”. For FOCUS 1.4, we should tag which schema version the raw file uses (e.g. add a column focus_version with value 1.4). That way we know if an export suddenly changes. We must ensure our raw schema allows the 47 new columns without dropping old ones. A quick approach is to add any new fields as nullable fields, so old data remains valid.

•     Conformed layer: a unified table combining providers, with standardized column names/semantics. Here we “map” each raw field into the conformed model. E.g. map AWS UsageType into a conformed dimension, rename fields uniformly, etc. In the conformed contract, include all FOCUS 1.4 columns (and the AWS x_ columns as separate fields). Write “schema migration documentation” so that for each new column (like PaymentDueDate or ContractCommitmentDiscountPercentage), we note its type and purpose. Also document which columns might be missing (for instance, InvoiceDetail fields might be null if not joined yet).

•     Semantic layer: this is where business logic is applied (e.g. cost allocation rules, definitions of actual vs amortized). The contract here is defined by the data model (e.g. star schema) that consumes the conformed fields. For instance, if we have a semantic model of “Total Monthly Spend by Dept”, specify exactly whether that uses BilledCost, EffectiveCost, or some computed metric. We must update those definitions for any changed FOCUS fields (more on that in Section 11).

•     Reporting layer (dashboards): the final output seen by analysts. Its contract is our chargeback policy, e.g. “each department’s reported total must equal its share of the invoice”. We will write acceptance criteria (below) to ensure this.

Assign a clear responsibility and contract action to every layer:

Finally, versioning: Label each dataset with its FOCUS version (e.g. table CostAndUsage_v1_4). Keep the old version side-by-side during parallel run. This way, stakeholders can sign off on the migration at a clear cutover point. Only retire the old contract when the new one is fully validated.

5. Integrate the BillingPeriod Dataset

FOCUS 1.4 adds a BillingPeriod dataset (6 fields: Created, Start, End, LastUpdated, Status, InvoiceIssuerName). Its purpose is to declare official billing period boundaries per account (even if they aren’t calendar months). To integrate it: first, ingest the raw BillingPeriod CSV or JSON from each provider. Then, join it to your cost data on billing account and currency. For example, in SQL:

SELECT c.*,
bp. BillingPeriodStart,
bp. BillingPeriodEnd
FROM ConformedCost c
LEFT JOIN BillingPeriod bp
ON c. BillingAccountId = bp. BillingAccountId
AND c. BillingCurrency = bp. BillingCurrency
AND c. BillingPeriodStart = bp. BillingPeriodStart

This ensures each usage row maps to exactly one billing period (or flags if it doesn’t). Use BillingPeriodStart/End to align time dimensions: if your reports grouped data by calendar month, consider whether you should switch to using the provider’s period field instead.

Implementation checklist:

• Load BillingPeriod as a separate table.

• Join it to cost data on account/currency (as above).

• In the semantic model, replace any hardcoded date windows with BillingPeriodStart/End from this table.

• Update any pipelines that slice by time so they respect billing boundaries. For example, allocate a charge on March 31 to the correct March billing period instead of April usage.

By explicitly linking costs to billing periods, we improve reconciliation accuracy (Section 6) and ensure allocations match invoice terms. If the BillingPeriod table shows “status = Closed” only for final periods, you can also use that to gate reports (don’t report on an invoice until its period is closed).

6. Use InvoiceDetail for Reconciliation

The InvoiceDetail dataset is FOCUS 1.4’s crown jewel for financial control. It contains each invoice’s metadata (InvoiceId, IssueDate, Issuer, PaymentTerms, PO number, etc.) and the amount billed in payment currency. We will use it to tie usage to actual invoice line items.

Implementation steps:

1. Ingest InvoiceDetail: Load the new InvoiceDetail table into the raw layer.

2. Join to usage: Each CostAndUsage row has an InvoiceDetailId in FOCUS 1.4 that links to the InvoiceDetail primary key. Use an outer join on InvoiceDetailId so you can sum costs by invoice and identify unmatched records.

3. Apply reconciliation logic: For each invoice and currency, compare the sum of PaymentCurrencyBilledCost in InvoiceDetail with the sum of BilledCost from usage. They should match within the approved rounding tolerance. FOCUS 1.4 defines a Rounding Variance Tolerance so cent-level differences do not create false failures. An illustrative query follows:

WITH Inv AS (
SELECT InvoiceId, SUM(PaymentCurrencyBilledCost) AS InvoicedAmount
FROM InvoiceDetail
WHERE PaymentCurrency = 'USD'
GROUP BY InvoiceId
), Cost AS (
SELECT InvoiceId, SUM(BilledCost) AS UsageAmount
FROM ConformedCost
WHERE PricingCurrency = 'USD'
GROUP BY InvoiceId
)
SELECT i. InvoiceId,
i. InvoicedAmount,
c. UsageAmount,
i. InvoicedAmount - c. UsageAmount AS Diff
FROM Inv i
JOIN Cost c ON i. InvoiceId = c. InvoiceId;

In testing, ensure Diff is zero or within the approved FOCUS tolerance.

4. Use invoice metadata: Apply fields such as PaymentTerms or ReferenceInvoiceId in reporting. If a provider records adjustments as separate line items, InvoiceDetail can expose them through InvoiceIssueStatus.

Impact analysis: This affects queries, transformations, and dashboards. Any BI metric that compared costs to invoices now should use the InvoiceDetail join. For example, our monthly budget report needs to sum actual invoiced spend, not just accumulated usage. We should update those queries to group by InvoiceId and use the detail’s PaymentCurrencyBilledCost (the invoice amount).

Checklist:

• Verify every InvoiceId in usage has a matching record in InvoiceDetail (unless the provider doesn’t support it).

• Apply FOCUS’s rounding variance tolerance instead of strict equality when summing costs (see glossary or spec’s appendix).

• Update dashboards: e.g. change “Total Billed Cost” widgets to use SUM(InvoiceDetail. PaymentCurrencyBilledCost).

By using InvoiceDetail, you make your system auditable: if AP questions “why is our bill $X?”, you can point to the exact FOCUS records (with IDs) that sum to $X.

7. Update ContractApplied JSON Parsing

FOCUS 1.4 changes the ContractApplied column format (in CostAndUsage) to use a formal JSON object schema. In practice, our ETL may have been parsing that JSON before (e.g. extracting a commitment ID or discount from it). Now the internal structure may be different (e.g. different key names or nesting). We must examine the new schema and update any JSON parsing logic.

Example impact: Suppose in FOCUS 1.3 we had code like:

SELECT JSON_VALUE(ContractApplied, '$. Id') AS ContractId,
JSON_VALUE(ContractApplied, '$. UnitPrice') AS DiscountPrice
FROM ConformedCost;

In 1.4, keys may be renamed or nested under ContractCommitmentId or a related object. The changelog warns that queries parsing the previous ContractApplied JSON structure must be updated to the new schema.

Implementation steps:

•     Compare a sample ContractApplied entry from 1.3 and 1.4. The FOCUS docs or appendices may show the new JSON schema (possibly in spec appendix).

•     Update ETL code or SQL expressions to match. For example, if values are now nested under ContractCommitmentId instead of flat keys, revise the JSON path accordingly.

•     If you have downstream columns that extracted these values (like a column ContractId in your semantic model), make sure they still populate.

Query and Dashboard impact analysis: Any measure or dimension that used a piece of the old ContractApplied (like attributing cost to a commitment) needs retesting. Check data for, say, the first few lines of a usage table: did ContractId still populate after parsing?

We should also document this in our data contract: note that ContractApplied changed schema, so direct mapping from it to business metrics must be validated. In many cases, FOCUS now provides equivalent fields directly (e.g. ContractCommitmentId column). So instead of JSON parsing, it may be simpler to use the new column value if it exists.

8. Preserve AWS Extensions Without Polluting the Standard

AWS’s FOCUS export includes proprietary fields. We must incorporate these carefully. For example, AWS’s five extra columns (x_ServiceCode, x_UsageType, etc.) are useful (they describe the AWS-specific SKU and usage type). Instead of merging them into our core data model, treat them as “x_” extensions.

Strategy: Add these columns to the raw and conformed tables with an aws_ prefix or place them in a JSON metadata column. In the raw ingestion stage, retain the x_ fields exactly as emitted. In the conformed schema, either keep documented aliases when analysts use them or move them to a separate extended-attributes table to avoid clutter. Do not disguise provider extensions as standard FOCUS columns; preserve their extension lineage.

Example:

# Pseudocode data contract excerpt
ConformedCost {...
aws_UsageType: string (NULLABLE) # from AWS x_UsageType
aws_ServiceCode: string (NULLABLE) # from AWS x_ServiceCode
aws_Discounts: string (NULLABLE)
aws_CostCategories: string (NULLABLE)
aws_Operation: string (NULLABLE)
}

Document each extension column’s meaning (AWS docs provide descriptions). This way, the semantic model can optionally include them if a report needs AWS-specific detail, but they won’t confuse metrics like TotalCost.

For example, we might build an AWS-specific dimension table of ServiceCode to human-readable names. Or, if not needed, ensure that aggregations (like cost by resource) ignore these fields.

Architectural note: This is a chance to apply solid cloud-engineering principles. Maintain clear separation of concerns: one part of the pipeline handles provider-specific data, including x_ columns, while another applies provider-agnostic business logic. A background in cloud architecture, networking, storage, and cost controls helps here; see Become a Cloud Engineer for related foundations.

9. Control Azure Export Schema Versions

Azure’s Cost Management allows choosing the schema version of exports. Ensure your subscription’s export is set to FOCUS 1.4 (or at least 1.3 as a stopgap) so you get new fields from day one. Because Azure combines actual and amortized costs in its FOCUS export, clarify which columns you’ll use. In FOCUS 1.4, we have BilledCost (the base invoice amount) and EffectiveCost (the amortized cost) for each row. Depending on reporting needs, either can be used. For example, cash-flow reporting might use BilledCost, whereas TCO analysis uses EffectiveCost.

Actual vs Amortized semantics: Azure’s improved export “combines actual and amortized costs” into one feed, meaning there’s no separate “Cost and Usage (Amortized)” file as before. In practice, this means every usage row includes both metrics. In our semantic model, decide whether to sum BilledCost (invoice-based) or EffectiveCost (resource-backed). For chargeback, usually we use invoice amounts (BilledCost). But for internal optimization, the amortized view shows true consumption cost.

Version rollover: The UI note is key: “Exports let you choose the latest or any of the earlier dataset schema versions”. That means we won’t accidentally break existing reports if the export is reconfigured. Confirm that we’re on FOCUS 1.4, but keep a backup export on FOCUS 1.3 (parallel run) until testing passes. If we needed more time, Azure could revert to 1.3 temporarily without rework. We should still expect to eventually adopt 1.4 fully, since it adds columns used in cross-provider analytics (like PricingCurrencyContractedUnitPrice etc.).

10. Add Conformance, Completeness, and Balance Tests

As we ingest and transform data, implement rigorous data quality checks. The FOCUS spec itself adds attributes like DatasetCompleteness and DeliveryHandling precisely to enforce integrity. We can mirror these with tests:

•     Schema conformance: Use a FOCUS validator (or custom script) to ensure our raw data matches the 1.4 spec. For instance, check that BillingPeriodStatus only has allowed values.

•     Completeness: For each dataset, assert that all required columns exist (no silent drops). For example, if a column like PaymentCurrency is suddenly NULL for all rows, alert immediately. Also, verify row counts: the number of usage rows should not mysteriously drop or grow without known cause.

•     Balance tests (glossary): Define and check key balances. For example:

Use automated tests (e.g. SQL queries in a CI job) to verify these after each ETL run. For completeness, also check DeliveryHandling: ensure we aren’t seeing duplicate rows across runs. If AWS appends daily and Azure overwrites monthly, our pipeline should catch duplicated primary keys, indicating a logic error.

Adding these tests early gives confidence and surfaces issues quickly. They also provide measurable acceptance criteria for sign-off.

11. Protect Chargeback, Showback, and Allocation

Even a successful schema migration can inadvertently skew chargeback calculations. For instance, new semantics around commitments and covered usage in FOCUS 1.4 could double-count savings if misunderstood. FOCUS 1.4 introduces unified rules for covering vs covered charges so that “EffectiveCost and BilledCost sum to the same total within a charge period”. In plain terms: prepaid commitments show up as credit entries (covering charges with zero effective cost), and usage draws against them as covered charges. Our allocation rules (e.g. assigning RI savings to teams) must follow these new semantics.

Concrete checks:

•     If we previously distributed Reserved Instance benefits manually, cross-check with the new FOCUS method. For example, the spec says every covering purchase’s cost flows to covered usage; ensure our models do not still include the covering purchase itself in any department’s cost.

•     Update cost categories: new FOCUS categories or flags (like CommitmentProgramEligibilityDetails) might change how we tag spend. For example, we can now distinguish spend that could have had a reserved instance (eligible) versus only those that actually did. If our showback reports separate “savings opportunities”, we should incorporate the new CommitmentProgramEligibilityDetails JSON column.

Finally, ensure that rate rounding (the new tolerance formula) is applied to avoided double-counting. For instance, if we allocated budget by daily usage rates, confirm that moving to FOCUS still yields identical aggregated totals.

Use the following allocation checks as a control matrix:

The bottom line: use this migration to tighten governance. After update, we should be able to explain every penny on a bill by walking through FOCUS data.

12. Backfill and Optimize Large Historical Datasets

With a new schema, historical data might need processing. Options: backfill vs forward-only. If our reports or audits go back years, we have two approaches.

•     Append new fields only for new data: Simplest, but old records have NULLs. Only works if historical comparisons aren’t needed or we don’t mind small data gaps.

•     Backfill historical records: Re-run transformations on old raw exports (if accessible) to populate new columns. For example, if we have older AWS CUR files, we could regenerate FOCUS_1_4 tables by reformatting them. This can be very time-consuming for large data.

For backfill, use partitioning and parallelism. In Spark or Hive, read the historical dataset and write it in date-based partitions instead of running a single-threaded load. Use an Amazon EMR cluster or a scaled data-warehouse cluster, and write to compressed columnar formats such as Parquet. The 47 new columns increase row width, so benchmark scan volume, shuffle cost, and downstream query latency before choosing the final layout.

Choose a backfill strategy based on audit requirements, runtime, and cost:

For large accounts, a temporary high-parallelism cluster may make a full backfill feasible, but size it from measured throughput rather than a fixed node count. If backfilling is too slow or too expensive, use the parallel run without full historical conversion and document the comparability gap.

Parallel-Run Acceptance and Financial Sign-Off

Run the old and new pipelines side-by-side for at least one full billing cycle (month/quarter) and compare key metrics. Define acceptance criteria and sign-off thresholds in a table like:

Treat these as starting thresholds and calibrate them to your financial materiality policy.

Also use a checklist at go/no-go:

• Data quality tests (from Section 10) all pass on new pipeline.

• Business totals match: key totals (e.g. invoice sums, budget allocations) differ by less than tolerance.

• Stakeholder review: Finance and engineering have reviewed a sample of reports.

• Monitoring in place: New ETL jobs are being monitored and log successfully.

• Rollback plan ready: If any critical discrepancy, ability to revert to old dataset.

Once all criteria are green, we can retire the old pipeline. Get formal sign-off from finance (say, CFO or controller), stating: “Migrated to FOCUS 1.4; all reconciliation and chargeback metrics validated.” Keep documentation of this sign-off in case of audits.

13. Prepare for the Next Spec Without Chasing Drafts

Look ahead but stay disciplined. The FinOps Foundation indicates “FOCUS 1.5” is coming (likely tackling price sheets and more SaaS support), but those are drafts. Avoid chasing every preview. Instead: subscribe to the official FOCUS repo or mailing list, and consider 1.4 migration done once certified stable.

Process-wise, treat each spec release as a version bump in our contract. Don’t allow ad-hoc schema changes. For example, when the next release is announced, block non-urgent code changes while you analyze it. Maintain a changelog in your own project so that schema updates and fixes are tracked. This prevents “spec drift” where different teams assume different versions.

And remember: the goal is stability. Embrace the fact that FOCUS is a living spec. Our own data contract should handle version upgrades (as we did here) so that the business isn’t blindsided next time.

14. Build a Cloud-Cost Data Portfolio Project

This migration work itself is a fantastic portfolio item to demonstrate your skills. When complete, treat it as a case study: show the architecture diagram of your cost pipeline, the transformation logic (maybe in a Terraform or SQL snippet), and the before/after results of parallel runs.

Portfolio elements:

•     An architecture diagram of the billing pipeline (you might draw one on Lucidchart or Visio).

•    Code snippets (e.g. SQL or Python) showing how you parsed InvoiceDetail or joined BillingPeriod.

•     A before/after report screenshot proving the totals match.

•     A data dictionary that maps key columns (like a snippet of the conformed schema with comments).

•     A project summary describing the challenge, actions, and outcome (like this article).

These artifacts are the kind of work Refonte Learning’s Cloud Engineering Program is designed to support. The relevant foundations include multi-cloud infrastructure, automation, security, and cloud cost optimization. The curriculum emphasizes hands-on, project-based work that can become a job-ready tech portfolio. FOCUS 1.4 itself is not presented here as a guaranteed named module, so verify current syllabus coverage before enrollment. This migration guide can still serve as a strong Cloud Cost Engineering case study because it demonstrates data contracts, provider normalization, reconciliation, testing, and financial sign-off.

Migrating to FOCUS 1.4 is substantial but manageable when the work is treated as a controlled financial-data change. Start by studying the changelog and mapping every new or altered field. Next, version the raw and conformed data contracts and update extraction, transformation, and loading logic. Then run the old and new pipelines in parallel until invoice, chargeback, and dashboard totals meet approved tolerances. The most important caveat is timing: do not cut over mid-billing-cycle or without complete tests and a rollback path. To build the multi-cloud, infrastructure, automation, security, and cost-optimization foundations behind this work, consider Refonte Learning’s Cloud Engineering Program. For guidance on evaluating training and internship options, see How to Choose the Best Virtual Tech Internship. Following this control-first approach lets you upgrade to FOCUS 1.4 without breaking a report, allocation, or dollar.