Staging draft Work in progress · For review; coverage and acceptance incomplete

Billing operations and usage investigations

Draft. Staff billing and usage views are partly connected. This overview explains the verified billing effects and usage meanings; financial-administration supplements remain in progress. Environment readiness and reader acceptance remain unverified.

Zerohive separates buying a service, confirming payment, applying the purchased change and investigating a billing problem. That separation matters when a payment has been reported but capacity has not changed, a checkout has expired, or an organization needs an approved correction. A support action should address the actual problem and preserve its history.

This overview explains the consequences for users, managers, buyers and workspace administrators. Privileged investigation and intervention procedures belong to platform staff. Being an administrator of one workspace does not grant authority to change the platform's billing records.

Platform-wide Billing Review and Operations queues require authorized billing staff. A read-only staff role does not, by itself, grant access to those queues. An access refusal is different from having no billing exceptions; use the approved support route to reach someone with the required authority.

Choose the right record

Record or view What it helps explain What it does not establish by itself
Provider event A billing notification received from the payment provider and its processing result That the amount was independently verified or a requested service change was applied
Billing workflow Progress of a particular purchase or commercial change That every later change to membership, capacity or provider billing has finished
Subscription The organization's current billing position and related payment timing A complete account of every failed payment or support action
Invoice or receipt The financial record associated with a charge or recorded payment That a separate workflow or workspace recovery has completed
Intervention audit A recorded staff adjustment, actor, time and supporting reason A payment receipt or proof that all downstream effects succeeded
Usage measurement Recorded consumption over a period or the latest available storage sample A live measurement, an invoice, or an explanation of why a payment failed

Commercial quotes and contracts have their own negotiation and conversion lifecycle. An accepted quote, a plan override and a paid purchase are different events. Review the applicable agreement and actual Billing outcome rather than assuming one record proves the others.

When a payment or change needs investigation

An unresolved provider event may lack a workspace association or have failed processing. A workflow may instead be waiting for checkout preparation, payment verification or application of the requested change. Failed, expired and manual-review records require different next steps. Recurring payment failures also have their own history and can affect access; see subscription and payment and workspace recovery.

A checkout link can remain stored after its original purpose has ended. Do not interpret an old link, an amount on a historical record or a generic payment label as an instruction to pay again. If the result of a payment is uncertain, retain its reference and ask the authorized billing owner to reconcile the provider and platform records first.

When requesting help, provide the workspace, the requested change, the relevant invoice or workflow reference, the time of the attempt and the visible result. Explain whether money was reported as collected and whether the expected capacity or access appeared. Share commercial and payment evidence through the organization's authorized support channel rather than a public documentation page.

Manual storage adjustments

Authorized billing staff can adjust storage allowances for an approved reason. This is separate from the customer's recurring storage-purchase journey. An adjustment does not itself prove that a payment was collected or that the provider's recurring charge was updated.

The workspace must be active or suspended. Its allowance follows the plan's storage-pack rules. Increases require an eligible plan and the configured pack increment; they are not available during trial. A reduction must match removable packs already held by the workspace. A requested reduction can be rejected even when subtracting that quantity would leave a positive overall allowance.

Cancellation timing also matters. Some packs expire immediately, while others remain available until the applicable term end. A recorded reduction request therefore need not produce an immediate lower limit. Review the resulting allowance and scheduled cancellation rather than relying solely on a confirmation message. The capacity guide explains storage limits and the ordinary customer purchase path.

Trial extensions and expiry

Staff can add a positive number of days to an existing trial while its subscription remains in the trial state and has a recorded end. The extension adds to the existing end date. It is not a general way to turn an active or past-due subscription back into a trial.

Trial expiry follows the configured fallback-plan process. It does not, by itself, establish automatic collection of the first paid charge. A commercial owner should confirm the actual purchase or conversion path instead of treating a trial-end date as a payment mandate. Read workspace creation and trials for the onboarding and expiry consequences.

Plan overrides and recurring billing

A manual plan override is a privileged correction that applies a target plan to the workspace. It can change capacity, product eligibility and access. Managers and workspace administrators should understand those effects with the commercial owner before a correction is applied.

Provider billing is a separate continuation. A zero-priced replacement can lead to cancellation of an existing provider subscription and a locally active subscription without provider billing. For a paid replacement with an existing external payment plan, synchronization also depends on a positive effective recurring charge. When there is no external payment plan, selecting a paid plan does not automatically create that missing arrangement.

Commercial terms can make the effective charge zero even when the plan has a positive catalog price. In that synchronization branch, the current implementation clears local provider references without requesting provider cancellation. Staff must verify the external subscription separately; a cleared local reference does not establish that charging has stopped.

For that reason, an override confirmation is not proof that the next provider charge is correct, that an outstanding amount was paid, or that a new recurring payment arrangement exists. Staff must check the local plan, the Billing records and any provider follow-up independently. The change and its reason should remain traceable.

Understand usage before making a decision

Hourly usage shows saved observations for a UTC calendar day; missing hours are not automatically filled with zeroes. A period total selects stored hourly measurements, so it is not an exact count between arbitrary minute-by-minute boundaries. Check the period, timezone and collection coverage before comparing it with another report. Storage recorded with an hourly observation can also differ from a later storage sample. These reads do not themselves charge an account or prove that an enforcement limit has been reached.

Usage helps explain how organizations consume the platform and where further investigation may be needed. It is separate from billing evidence: a storage reading is not an invoice, a high request count is not proof of a higher charge, and a change in consumption does not authorize a plan change.

The staff console has four intended views. Summary gives an overall position; Top Tenants ranks a selected number of organizations; Breakdown compares their requests, storage and limits; Trends & Pressure combines daily measurements, growth signals and proximity to limits. Organization-wide administrators use their own capacity guide. They do not gain access to other organizations' measurements through these public explanations.

Measurement How to interpret it
Active organizations in the platform summary Organizations currently active in the platform, including those with no recorded usage in the selected period
Request volume and errors Recorded requests and their outcomes during the chosen period; compare counts with the period and population stated
Average response time An average weighted by request volume; it does not describe the slowest request or guarantee every user's experience
Object/file storage The latest available object-storage sample at or before the period end
Database storage A separate stored-data measurement; add it to object storage only when explicitly calculating a combined footprint
Storage growth The change between sampled storage values; it can be negative, and a missing earlier sample affects interpretation
Traffic growth in the current implementation Total requests during the chosen period; it is not an increase against the preceding period
Limit pressure Usage compared with a current allowance; a missing limit makes the percentage unavailable rather than proving zero use

Storage samples can predate the selected period. A chart therefore does not prove that a fresh storage scan occurred at the time it was opened. Current active-organization membership also governs these platform views, so an old date range is not a complete reconstruction of the platform's membership at that earlier date.

Comparisons need matching scope. A top-ten list describes a selected group, not the entire platform. Summary storage averages include the whole current active estate. Separate maximum object and database readings can belong to different organizations; their sum is not a historical platform peak.

Reading usage during a billing investigation

An organization's billing view can use its current subscription period, while a platform-wide usage view defaults to a different reporting window. If the subscription has no complete period, the billing service fills missing dates from a 30-day window ending now. Check the actual dates before comparing counts or describing them as the current billing period.

Current storage is the latest available sample by the reporting end. Peak and average storage in the organization's billing summary use recorded hourly values within the period. Those records can have different coverage, so the current value can be higher than the recorded hourly peak. The average is not a continuously measured average across every hour. Missing measurements can also be returned as zero; zero alone does not prove that no data is stored.

These values help support explain an investigation. They do not establish the invoice amount or authorize a financial correction. If the view cannot load, treat it as unavailable information and retain the organization, dates and symptom for support. The current frontend still needs to show the full period and storage context available in the service.

Growth, alerts and capacity planning

Managers should use a sustained, understood change in usage to frame a capacity conversation. First confirm the time window, sample context and affected organizations. Request totals over a week and over a month cannot be compared as though the durations were equal.

The current API-call pressure calculation compares calls in the chosen window with a monthly limit. A custom window does not resize that limit. Storage pressure compares object storage with the effective allowance; database storage is recorded separately. A reported breach is a signal to review the policy and impact, not evidence that a charge, suspension or automatic upgrade occurred.

An anomaly flag highlights a qualifying increase in request or server-error counts compared with an equally long preceding period. It does not identify the cause. For example, 2.7 times the preceding count is a 170% increase. When the previous count is zero, there is no finite percentage increase; the new activity and its actual count need explanation.

Some distribution views use “inactive” to mean currently active organizations without positive measured usage. That label does not mean those organizations are suspended. Additional labels such as “API-only” and “storage-heavy” overlap the activity grouping; they should not be added together as independent shares of the estate.

Executives can use these distinctions to assess concentration, capacity and service quality without treating operational indicators as financial or contractual guarantees. Workspace administrators and support should retain the organization, exact period, visible symptom and measurement when asking for help. Ordinary users need only report the impact they experienced; they should not be expected to diagnose the platform's metrics.

The current Usage views accept reporting dates and supported metrics, preserve the selected window across views, keep object and database storage separate, and page the returned selection. Some population labels, chart composition and unavailable-comparison details still need work. Confirm the displayed period and measurement before relying on a screen for a business decision. If data cannot be loaded, an unavailable view is not evidence that usage is zero.

Refunds and payment reversals

A refund request starts an approval process. It is not confirmation that money has been returned. Authorized staff check the organization, paid invoice, amount and reason, and a different administrator makes the decision. After approval, the payment provider's matching final result must be confirmed. Provider processing and unresolved outcomes can delay completion; approval does not promise an immediate return of money.

The remaining refundable amount accounts for existing requests and recorded reversals, including some still pending. Several simultaneous requests cannot each treat the full invoice as available. Tax is allocated across partial refunds, with the remaining tax assigned to the final remaining refund.

If money was already refunded outside this process, staff record and verify that external event. They should not request a second payment merely to make records agree. A chargeback is recorded separately with evidence and an independent decision. An external reversal can be financially verified while related credit recovery still needs attention.

For HiveAI credit purchases, a refund can require recovery of the credits associated with the purchase. Eligibility therefore depends on more than the cash amount. Staff must distinguish the payment outcome from the credit-account outcome and explain both when they affect the organization.

When a provider response is lost or uncertain, staff investigate the existing operation before taking another action. A delay does not prove that no refund occurred. Retain the organization, invoice reference, requested amount and currency when using your authorized support route. Do not send passwords, access tokens or full payment-card information.

Users and workspace administrators should ask for the recorded outcome and remaining follow-up. Managers should consider the effect on purchased capacity or credits. Finance and executive readers should distinguish approval, provider-confirmed refunds, externally verified reversals and unresolved cases when assessing the financial position.

Taxes and credit prices

Country tax rules are versioned application settings. A saved rate does not establish its legal correctness or prove that tax has been remitted. Historical billing events use the applicable stored tax evidence. Missing configuration requires investigation and must not be interpreted as a legal exemption.

Tax reporting uses a stated period, country and currency. It includes paid invoices in that period and tax allocated to refunds completed or external reversals verified in that period. A reversal can concern an earlier purchase, so a period can contain refund-only entries or negative net tax. Gross collections and net sales describe the included invoices; they are not totals already reduced by all refunds. Different currencies remain separate.

HiveAI prepaid pack prices are maintained by pack and currency, with revision history and an active state. Availability also depends on the active plan and its eligible catalog items. The available-price lookup prefers the billing-currency price and can fall back to an active USD price. Removing one currency's active price does not necessarily withdraw the pack. Confirm the currency and offered amount before a purchase; this guide does not advertise fixed prices.

A platform-funded HiveAI adjustment addresses an eligible settled charge arising from a platform defect. It restores the charged credits with an evidence record. It differs from returning money for a purchased pack and does not change its selling price. An unresolved operation must meet the service's settlement and reconciliation requirements before receiving such an adjustment.

Financial administration is implemented in backend services, but matching console journeys have not been verified in the inspected final design or frontend. These explanations describe financial rules and support expectations; they do not imply that ordinary users have self-service refund or tax controls.

Oversight and responsibility

Executives and procurement owners need the agreed commercial scope, approval context and resulting financial position. Managers need to know whether capacity or access has changed. Workspace administrators should verify the organization and affected users before escalating a problem. Ordinary users and external participants should use their normal workspace support route rather than attempting platform billing interventions.

Platform staff use separate provider-review, operations, tenant-billing and intervention-audit views. A queue is a selected set of records, not necessarily the complete financial history. Totals calculated from the visible page should not be read as full-estate totals. A blank page, missing association or unavailable secondary read needs investigation before it is described as “nothing to review.”

The frontend for billing operations still has gaps in paging, status translation, record navigation, checkout-summary display and intervention context. Financial rules and internal procedures now have draft explanations; screen journeys, environment delivery and audience acceptance remain open. The usage overview and payment guide explain the verified customer-facing foundations.

Platform-wide revenue, subscription, country, growth/trial and licence reporting is documented separately in the Platform Insights overview. This feature retains ownership of individual billing investigations and interventions.

Zerohive documentationStaging draft · 22 Oct 2026

Search documentation

Search guides, platform concepts and tasks.

↑ ↓ to move Esc to close