Understanding billing records¶

Billing has several records because a subscription, a purchase request and a completed payment answer different questions. Use the record that matches the decision you need to make, and keep the organization and payment reference together.

The intended Billing task guide follows the inspected Final Screens. The frontend is still being completed; the explanations here describe the implemented record rules without assuming that every field already appears on screen.

Which record to use¶

Current Billing, history, workflow and invoice routes load backend records. Their directories are paged, and most visible search/filter controls narrow the fetched page rather than search the whole account. The subscription overview shows only a few recent records; its featured workflow need not be your unresolved request. A missing result, failed recent-activity read or empty filtered page is therefore not proof that no payment or request exists. Keep the original reference, clear filters or inspect another page before deciding what is missing.

Being responsible for finance does not automatically grant access to these records. Ordinary workspace Billing requires current organization-administrator eligibility. A product licence or organization-head title alone does not substitute for it. See billing access and recovery.

Read the subscription summary as a combined view¶

The summary combines Billing's account information with the platform's plan allowances and a usage summary. Those parts can update at different times. A recently completed change may therefore need reconciliation across the subscription, purchase workflow and resulting allowance.

The recurring amount describes the billing snapshot. It is not, by itself, an instruction to pay that amount again or the final total for a new checkout. A new purchase has its own saved price, tax, currency and terms.

A status associated with a recent provider notification is also not a complete decision about product access. Paid coverage, trial dates, grace, member eligibility and product assignment have separate rules. Use subscription coverage when establishing whether a person can work.

Treat an absent allowance or usage value as missing information. Do not read a blank value as zero, unlimited allowance or proof that no subscription exists. The usage period also matters: when subscription dates are unavailable, the service can use a recent thirty-day period. That fallback is not a newly granted subscription term.

Follow a purchase through its workflow¶

A workflow describes a saved billing operation, including the intended plan or capacity change, original financial summary and processing status. It can contain separate times for creation, last update, payment verification and completion.

An amount retained in a completed workflow is historical purchase information. It does not become a second debt merely because the amount is still displayed. Equally, a checkout link alone does not confirm that payment is currently required, that the link remains usable or that the operation is safe to repeat.

For a scheduled change, check the recorded effective date and the applied result. A saved future change is not evidence that the new allowance has already taken effect. See plan changes, checkout creation and controlled checkout recovery for the corresponding rules.

The general workflow list can be filtered by status. A record absent from one filtered page can still exist. The initial-workspace checkout recovery view is a separate selection and is not a complete billing history.

Use a saved checkout summary¶

For an unfinished payable request, review the saved plan or change, billing currency and Amount due now before continuing. The current frontend labels a completed request's total Recorded Total: it describes that saved transaction and is not another amount to pay. A payment can be verified while its subscription or purchase is still updating. Missing or inconsistent financial details need checking; they are not confirmation of zero cost. A scheduled change that requires no payment can still be awaiting its effective date and application.

Read a plan change's target plan separately from the current plan. An additional-seat purchase describes the seats being added; that number is not the total licensed population. Storage changes also describe the saved request. Where the current frontend shows a billing term as Not provided, have the relevant billing record or approved terms confirmed instead of inferring a term from the charge. That display limitation does not establish what every backend contract contains.

When a summary needs payment, use the checkout link it currently offers. The link can be unavailable while the page loads or refreshes, or when current payment details cannot be confirmed. Refresh the original summary rather than reuse a link copied from an earlier view. During preparation, the page checks again for a limited period while it stays open. If checking stops, use the available refresh action or ask for help with the original record; a stop is not proof that the provider failed or that another purchase is needed. See checkout creation for the separate stages of preparation, payment and application. If you have only an older link, reopen the original billing record before continuing.

Initial workspace payments continue through Workspace Access. A corresponding Tenant Admin history record does not move that payment-recovery step into Tenant Admin. Keep the original workspace and purchase reference when returning to the appropriate entry point.

Interpret an assistant's billing summary¶

Where billing assistance is available in your environment, it uses current organization-administrator access to read selected commercial records. The assistant may return a limited selection rather than a complete history. An empty answer does not establish that no invoice, purchase or payment attempt exists.

A summary can help explain the plan, a recorded purchase or whether receipt information is available. It does not make a payment, issue purchased capacity or fund the AI credit balance. A statement that a receipt is available also does not mean the assistant has supplied a downloadable receipt.

If a summary says that no payment is required but the financial details are missing or disagree with the saved purchase, have the original workflow checked before relying on that conclusion. Missing information must not be treated as confirmed zero cost.

Completing a protected billing form and completing the purchase are separate outcomes. The form can be associated successfully with the saved workflow while payment is still outstanding. Confirm the recorded payment and the applied result separately. If the return from that form expires, becomes unavailable or loses access, keep the original purchase reference for recovery; do not create a replacement payment solely to obtain another confirmation.

These are interpretation rules for the implemented billing boundaries. They do not establish that assistant entry, every summary field or the return journey is available in the current frontend. The Billing task guide retains the inspected intended journey and its availability limits.

Understand invoice and receipt availability¶

The ordinary invoice list includes only invoices currently recorded as paid. Pending verification, failed and other nonpaid records are excluded. The same paid-only rule applies when requesting an invoice's receipt details.

An empty list therefore does not prove that no payment attempt exists. A missing receipt might relate to a different organization, a nonpaid record, an unknown invoice or a failed lookup. The saved workflow and provider transaction reference are useful evidence for reconciliation.

Receipt details include the recorded total, net amount, tax amount and rate, currency and related transaction. An external receipt link is optional. The record service does not itself generate a downloadable PDF, so do not assume that every paid entry has a file available.

The receipt view also does not expose every internal subscription-coverage field. Use the accepted subscription period and payment coverage explanation to establish the period of service, rather than inferring it from an invoice issue date.

Interpret history and ordering¶

Billing history includes more than plan changes. It can record payment, subscription and workflow activity. An activity is evidence that its event was recorded; it is not a separate charge or proof that every downstream action finished.

The lists use different dates: workflows sort by creation, history by event occurrence, and invoices by occurrence when available or otherwise issue time. A workflow updated today can still appear behind one created more recently.

Records can change while you move between pages. Totals and page contents should not be treated as an immutable accounting export. Keep references when comparing a particular event across views.

A delayed update can change an existing workflow status or history entry while later payment or completion information remains recorded elsewhere. If those records disagree, retain the original reference and have the payment and applied result reconciled. A refreshed status or refreshed history entry is not, by itself, a reason to pay again.

When information is missing or inconsistent¶

Confirm the organization and the original reference, then distinguish three situations: no eligible record was returned, you are not authorized to read it, or the service could not obtain the result. A failed request is not evidence of a failed payment.

An administrator or authorized support reviewer can use the workflow reference, invoice or transaction reference, currency, amount and approximate time to investigate. Describe which records disagree. Avoid making a replacement payment just to force the records to match.

For business reporting, reconcile accepted payments with applied subscriptions or purchases. Do not calculate outstanding debt from retained workflow amounts, treat each history row as revenue or assume that the first page contains all paid invoices.