FOCUS invoiced and amortised cost
Must FOCUS BilledCost and EffectiveCost totals match within every billing month?
FOCUS 1.4 assigns BilledCost to invoiced charges in the billing period and EffectiveCost to recognised resource, service or commitment cost in the charge period. Their billing-period totals can differ when a covering purchase and its usage cross periods, accounts or datasets. The specified equality applies across related covering and covered charges over the covering charge period when both sides are present.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No buyer commitment or invoice reconciliation was inspected.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS non-originator zero-cost rows
Does a zero FOCUS BilledCost or EffectiveCost row establish that a service was free?
FOCUS 1.4 requires BilledCost to be zero for records generated by an entity that does not invoice the charge, and EffectiveCost to be zero for records generated by an entity that did not originate it. These rules prevent duplicate cost across datasets. Covered usage can also have zero BilledCost. Zero in one dataset therefore does not establish that no charge exists elsewhere.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Related invoicing data has not been inspected.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS commitment savings without double counting
Can I sum every FOCUS ListCost and ContractedCost row to calculate commitment savings?
FOCUS 1.4 warns that commitment-covered costs require excluding either covering Purchase rows or covered Usage rows when aggregating ListCost and ContractedCost, depending on cash or accrual purpose. Including both can count the same coverage twice. These price baselines require their applicable unit and quantity rules; their difference is not independently verified realised savings.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual savings and the counterfactual purchase price remain unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS pricing quantity versus consumption
Can I multiply FOCUS ConsumedQuantity by a unit price instead of PricingQuantity?
FOCUS 1.4 distinguishes metered ConsumedQuantity in ConsumedUnit from PricingQuantity in PricingUnit. Their granularity or interval may differ. PricingQuantity is used with the applicable SKU unit price to produce ListCost or ContractedCost when the required values are present. Substituting consumption without its documented conversion can produce an invalid charge estimate.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The supplier meter and conversion have not been tested.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS null consumption and unused commitments
Does a null FOCUS ConsumedQuantity mean the record has no usage-related cost?
FOCUS 1.4 requires ConsumedQuantity to be null for non-Usage categories, unused commitment Usage charges and records with null SkuPriceId. Correction records can also have null consumption under the stated conditions. Null has a defined applicability meaning; treating it as measured zero can hide unused commitment cost or distort a usage denominator.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Missing measurement and true zero have not been distinguished in buyer data.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS commitment quantity and coverage units
Can I compare FOCUS CommitmentDiscountQuantity directly with raw GPU hours or token counts?
FOCUS 1.4 expresses CommitmentDiscountQuantity in CommitmentDiscountUnit, depending on the provider commitment category and flexibility rules. It can differ from consumption and pricing quantities. Purchase quantities and Used or Unused usage quantities describe different sides of coverage. Mixing raw workload units or both sides without reconciliation need not measure commitment utilisation.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Physical GPU activity and workload efficiency are not established.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS commitment eligibility versus availability
Does FOCUS CommitmentProgramEligibilityDetails prove a commitment can be bought or applied now?
FOCUS 1.4 lists programs that could potentially cover a charge whether or not a commitment was applied. The field must not reflect temporary purchase restrictions such as account configuration or quotas, and excludes commitment periods and payment options. It identifies an eligible pool, not current availability, approved terms or achieved coverage.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Current restrictions, negotiated options and authority are unknown.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS reserved capacity and physical use
Does FOCUS CapacityReservationStatus Used prove the reserved GPU was busy?
FOCUS 1.4 uses CapacityReservationStatus to describe whether a charge consumes the identified reservation or represents its unused portion. This is a charge-allocation status. It does not supply GPU occupancy, useful work or successful inference measurements; those require workload and hardware evidence correlated to the same resource and interval.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- No hardware utilisation or agent outcome was measured.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS split charge conservation
What must remain consistent when a FOCUS origin charge is split across teams?
FOCUS 1.4 requires summable costs and quantities across allocated charges to reproduce the origin charge, while dimensions and non-summable metrics such as unit prices retain origin values when present. A split redistributes a charge rather than creating cost. Arithmetic conservation supports consistency review but does not establish fair allocation or correct metering.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Underlying metering and allocation fairness remain unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS allocation method and measured factors
Does a FOCUS AllocatedMethodId establish how a shared AI bill was divided?
FOCUS 1.4 requires an AllocatedMethodId for generator-calculated splits and documentation identifying that method. AllocatedMethodDetails should be present for these charges and, when present, describes factors and ratios; ratios across allocated charges must total one. The identifier alone does not expose measured factors or demonstrate correct application.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual factors and implementation were not observed.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS origin tags versus allocated tags
Can origin resource tags alone identify the team charged by a FOCUS cost split?
FOCUS 1.4 separates AllocatedTags for allocated charges from resource tags already present in Tags. AllocatedTags must not repeat those resource tags and may be null even for a split charge. The originating resource owner and allocated recipient need not be interchangeable; absence of allocation tags does not prove the origin owner accepted that share.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Buyer ownership and approval mappings are unknown.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS replacement corrections
Should I append a corrected FOCUS Replacement snapshot to the previous export?
FOCUS 1.4 Replacement corrections use a complete snapshot superseding earlier artifacts for the same delivery scope. Adding both can double count unchanged records. Because changes are not separate entries, the latest snapshot alone does not preserve correction history; versioned artifacts need separate retention when that history is required.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Buyer import and audit-retention behavior is unknown.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS delta corrections and aggregation
Does the latest FOCUS Delta artifact contain the complete corrected bill?
FOCUS 1.4 Delta corrections append additive changes while preserving earlier artifacts. A complete view requires all artifacts for the delivery scope. Net changes adjust totals without necessarily reversing the original record explicitly, providing less inherent change detail than Ledger corrections. A latest-delta-only calculation can omit the original amount and previous adjustments.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Completeness of the buyer delivery chain is unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS ledger correction reconstruction
How should I distinguish a FOCUS Ledger reversal from a second charge?
FOCUS 1.4 Ledger corrections append explicit reversals and re-entries as applicable: a reversal changes additive metric signs while other columns match the original, and a corrected record can follow. All artifacts remain relevant to the scope aggregate. Negative and positive rows need their correction context; their presence alone does not establish duplicate billing or a cash refund.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Financial transfers and the complete buyer ledger are unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS hybrid delivery mechanisms
Can one FOCUS import use the same append rule for open and closed billing periods?
FOCUS 1.4 permits hybrid Overwrite and Append delivery with documented conditions for each mechanism. An implementation may overwrite open-period snapshots and append closed-period corrections. Artifacts must be interpreted within their delivery scope and mode; treating every file as additive or every file as replacement can respectively duplicate or lose charges.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual provider delivery and importer behavior have not been tested.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS native data exclusions
Does a FOCUS 1.4 export automatically preserve every native billing field?
FOCUS 1.4 requires custom columns for native fields not represented by standard columns, except publicly documented justified exclusions unrelated to invoice reconciliation. Reconciliation-required fields cannot use that exclusion. Included custom values must retain fidelity and summable totals. Providers may require explicit column selection, so a delivered export still needs its configuration and exclusions checked.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Buyer export conformance and field coverage remain unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS completeness flags and coverage
Does FOCUS DatasetInstanceComplete or TimeSectorComplete prove every expected charge is present?
FOCUS 1.4 describes these flags as the generator assessment under its documented definition of completeness. DatasetInstanceComplete applies to non-time-series instances; TimeSectorComplete applies to time sectors. A true flag does not independently reconcile expected workloads, excluded accounts or late charges. The declared scope must be compared with the scope the buyer actually needs.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual coverage and missing charges have not been checked.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS metadata versus charge freshness
Does a recent FOCUS RecencyLastUpdated timestamp mean the underlying cost data is recent?
FOCUS 1.4 distinguishes when the recency metadata object was updated from when dataset-instance or time-sector data was updated. RecencyLastUpdated alone cannot establish charge freshness for the period being assessed. Inspect DatasetInstanceLastUpdated and the relevant TimeSectorLastUpdated alongside completeness and delivery scope.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- The buyer feed freshness has not been measured.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS provisional invoice identifiers
Does an InvoiceId in FOCUS prove the supplier has issued the invoice?
FOCUS 1.4 permits InvoiceId and InvoiceDetailId to be generated for provisional invoices before issuance. Their presence identifies an association, not final publication or payment. Check InvoiceIssueStatus and the issuer document before treating an identifier as a final obligation; a provisional identifier can accompany preliminary data.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual invoice publication and payment state are unknown.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS issued invoice reopening
May a FOCUS invoice silently return from Issued to Open during a correction?
FOCUS 1.4 prohibits Issued-to-Open status transitions unless the customer explicitly requests or approves them. Corrections not affecting invoice reconciliation may occur regardless of status, yet can affect allocation and traceability. Consumers need the transition, approval and correction context rather than assuming issued data never changes.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Approval and actual correction behavior were not observed.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS invoice line identity and grain
Can FOCUS invoice lines be reconciled by SKU alone across an invoice?
FOCUS 1.4 allows InvoiceDetailGrain to vary between records within one invoice. It must include every property defining line granularity, including custom properties without a standard equivalent. InvoiceDetailId identifies a record within its InvoiceId. A fixed SKU-only join can merge distinct lines or multiply charges when the actual grain differs.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Buyer invoice joins have not been tested.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS corrective invoice lineage
How does FOCUS distinguish a corrective invoice from a self-contained invoice?
FOCUS 1.4 requires ReferenceInvoiceId to point to the original InvoiceId when the current invoice adjusts another, and to the current InvoiceId otherwise. This supplies adjustment lineage rather than proof of refund or payment. Reconcile the referenced document, issuer and affected charges before closing a correction.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Referenced documents and transfers have not been inspected.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS currency conversion at different grains
Does zero PaymentCurrencyBilledCost on a FOCUS line mean nothing is payable for that line?
FOCUS 1.4 permits payment-currency amounts in a separate aggregate record. A granular line can have non-zero BilledCost and zero PaymentCurrencyBilledCost, while the aggregate has the opposite pattern. The documented PaymentCurrencyInvoiceDetailId relationship links the grains. Reconcile the group and currency basis before interpreting a zero line amount as no obligation.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual conversion and settlement remain unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS pricing, billing and payment currencies
Can FOCUS pricing currency, billing currency and payment currency be treated as one monetary unit?
FOCUS 1.4 permits PricingCurrency to be national or virtual, while PaymentCurrency is the national currency in which settlement is made or expected. PricingCurrencyEffectiveCost is the pricing-denominated equivalent of EffectiveCost with the same recognition basis. These denominations and roles require documented conversion; amounts cannot simply be added as one unit.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Conversion rates, bank fees and settlement are unknown.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS seller, host and invoice issuer roles
Does FOCUS ServiceProviderName identify both the cloud host and the invoice issuer?
FOCUS 1.4 distinguishes service provider, underlying host and invoice issuer. Marketplace services identify the seller; white-label reseller services identify the reseller. HostProviderName can default to ServiceProviderName when the underlying host is not exposed or selected. Reporting names do not independently authenticate a merchant or prove the physical host.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual identity and hosting remain unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS applied contract commitments
Does a ContractApplied entry establish that an entire commitment has been fulfilled?
FOCUS 1.4 associates a charge with one or more commitments and reports applied cost or quantity and unit. Commitment IDs are unique within the provider and have one parent contract; applied cost uses BillingCurrency. A charge association supplies a progress input, not a complete balance or proof of fulfilment across every relevant charge and interval.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Complete progress and commercial terms are unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS commitment status and replacement
Can a proposed or superseded FOCUS commitment be treated as currently available coverage?
FOCUS 1.4 separates Proposed, Pending, Active, Exhausted, Expired, Canceled and Superseded states. Proposed has no current financial impact, Pending begins later, and Exhausted has no remaining value despite being in effect. A modification requiring a new ID makes the previous record Superseded. Current coverage needs applicable dates, state and version lineage.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual remaining balance and signed terms are unverified.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS continuous commitment intervals
Can later usage recover unused coverage from an earlier FOCUS Continuous commitment interval?
FOCUS 1.4 describes Continuous commitments as fixed coverage per fulfilment interval without unused benefits carrying forward. Discontinuous commitments use an aggregate window; Full Period must be Discontinuous. Annual usage alone cannot establish utilisation of an hourly Continuous commitment. The model and interval must match the calculation.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Actual interval utilisation has not been measured.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice
FOCUS spend versus usage commitments
Does a missing FOCUS ContractCommitmentCost mean the commitment has no value?
FOCUS 1.4 requires ContractCommitmentCost for Spend but permits null for Usage. ContractCommitmentQuantity is required for Usage and may be null for Spend. Quantity uses the provider commitment unit, while cost uses BillingCurrency. Missing cost can indicate a quantity-based obligation rather than zero value.
Documentation reviewed 2026-10-24. Primary source.
Boundaries
- Monetary valuation of buyer usage commitments is unestablished.
- FOCUS conformity, invoice correctness, physical utilisation, actual payment or business outcome has not been independently verified.
- Buyer deployment testing, live runtime enforcement, certification or permission to act
- Expanded capabilities or licences for existing INDEX executables
Complete record JSON · Exact free preview JSON · Source review
Required source attribution and distribution notice