A partially charged request should appear with a distinct, neutral “Partially charged” billing status, the amount actually charged, and any unresolved difference from a valid requested, estimated, or authorized amount. The UI should separate request execution from billing, explain the reason only when verified, and state whether the billing result is final or whether customer action is required only when the system knows.
The short answer: show a distinct status, the settled amount, and what remains unresolved
Do not hide a partial charge under a generic Succeeded or Failed label. Those labels usually describe request execution, not the financial outcome.
A clear activity entry should answer four questions:
- What happened to the request? For example, completed, failed, cancelled, or still processing.
- What was charged? Make the final charged amount the primary monetary value when settlement is complete.
- What is the comparison amount? Show the requested, estimated, or authorized amount only when it exists, and label it precisely.
- What remains unresolved? Explain the difference, billing finality, and next action when those details are available.
For example, an entry might show Request: Completed and Billing: Partially charged. It could then display Charged: $6.40, Estimated: $8.00, and Difference: $1.60 not charged. These values are illustrative; actual labels should reflect the billing model and data available to the application.
Avoid implying that the difference will be refunded, collected later, waived, or retried unless a known workflow state supports that statement.
What “partially charged” means—and what it does not mean
As a practical UI definition, a request may be described as partially charged when its final settled charge is lower than an available requested, estimated, or authorized amount. This definition depends on having both a valid comparison amount and a final charge.
The comparison amount needs an explicit label because these concepts are not interchangeable:
- An estimate is a forecast and may change when actual usage becomes known.
- An authorization confirms that an amount may be available for charging, but it is not necessarily a settled charge.
- A hold can temporarily affect available funds without representing final settlement.
- A settled charge is the amount ultimately posted through the applicable billing process.
- A credit reduces an amount owed or creates an account balance according to the billing workflow.
- A refund reverses or returns some or all of a previous charge.
- A partial payment describes payment against a larger balance and is not automatically the same as a partially charged request.
A lower final charge does not, by itself, reveal why the difference occurred. It should not be attributed to request failure, cancellation, routing, caching, batching, quantization, GPU scheduling, or another mechanism unless event-level data establishes that connection.
If there is no valid requested, estimated, or authorized amount, the interface may be better served by showing the charged amount and its billing state without calculating an artificial remainder.
Separate the request outcome from its billing status
Request execution and billing are different dimensions. Combining them into one status forces users to guess whether Completed means the request ran successfully, the charge settled fully, or both.
A two-field pattern makes the distinction explicit:
- Request status: Completed
- Billing status: Partially charged
Other combinations may also be valid. A completed request could have billing that is pending, while a failed request could have a settled charge for usage already consumed. The interface should display only combinations that the underlying system can verify.
This separation also improves filtering and investigation. Operations teams can search for execution failures without mixing them with billing exceptions, while finance teams can isolate partial or pending charges regardless of technical outcome.
Status color should not carry the full meaning. Pair color and icons with text labels so the distinction remains understandable in exported records, assistive technologies, and low-contrast environments.
What the activity row and detail view should show
The activity row should communicate the essential financial result without becoming a miniature invoice. Its primary monetary value should be the amount actually charged, or the amount currently recorded if settlement remains pending.
A useful summary row can include:
- Billing status: Partially charged
- Charged amount: The final amount, when settled
- Comparison amount: Requested, estimated, or authorized, when available
- Uncharged difference: Clearly described as unresolved, not charged, or otherwise classified by known state
- Request status: Kept separate from billing status
- Timestamp and request identifier: Enough context to locate the event
- Details link: Access to the fuller billing explanation
The detail view can add model or service name, usage quantity, pricing basis, currency, relevant timestamps, reason description, related event identifiers, billing finality, and required action. If a field cannot be supported reliably, omit it or label it unavailable rather than filling the gap with an inferred explanation.
Amount labels should remain semantically precise. For example, do not place an authorization under a generic Total heading or present an estimate as though it were settled. When multiple currencies or units are possible, display the applicable currency and usage unit beside the value.
Illustrative microcopy for known and unknown billing states
The following examples are recommended patterns, not current Token Forge Cloud interface text. Amounts and reasons are illustrative.
When the reason is known and the charge is final
> Partially charged > Charged: $6.40 of an estimated $8.00. > Difference not charged: $1.60. > Reason: Final billable usage was lower than the estimate. > Billing state: Final. No action required.
Use this pattern only when the reason, finality, and lack of required action are all confirmed. If the first amount was authorized rather than estimated, the copy should say authorized.
When the reason is unavailable
> Partially charged > Charged: $6.40. Authorized amount: $8.00. > Difference: $1.60. > Reason unavailable. View billing details for the current status.
This wording acknowledges the missing explanation without assigning blame or inventing a cause.
When the billing result may still change
> Partially charged — settlement pending > Currently charged: $6.40. Estimated amount: $8.00. > The billing result is not final and may be updated after settlement. > No action information is currently available.
Pending language should appear only when the billing system identifies the state as pending. Similarly, Under review, Adjustable, No action required, or a support instruction should be used only when backed by the actual workflow.
Handle pending settlement, retries, adjustments, credits, and refunds distinctly
Related financial events should not be collapsed into the meaning of Partially charged. Each event communicates a different stage or change:
- Pending settlement means the financial result is provisional and may change.
- Retry means another processing attempt occurred or is planned; it does not automatically explain the amount already charged.
- Split processing means portions of a request or charge were handled separately and should be connected through related identifiers when supported.
- Adjustment changes a previously recorded amount under a defined billing process.
- Credit creates or applies a reduction but is not the same as an uncharged remainder.
- Refund reverses an earlier settled charge and should reference that original event where possible.
When later events alter the financial position, preserve the history instead of silently overwriting it. A partial charge can remain visible as the original event, with a linked adjustment, credit, or refund showing what changed and when.
The interface should also prevent double counting. A retried request may create a related technical event without creating another charge, or it may produce a separate billable event. The display should follow the underlying records rather than assume either outcome.
Keep the activity UI consistent with invoices and financial records
Users should encounter the same amount meanings across the activity list, event details, invoice, and wallet or ledger view. Consistency does not require every surface to show identical detail, but shared values should use the same terminology, identifiers, currencies, timestamps, and reason descriptions.
If activity data is provisional, label it as provisional and explain how it relates to later settled records. If an invoice groups multiple request-level events, provide enough identifiers or date ranges to support reconciliation without implying a one-to-one relationship that does not exist.
Implementation review checklist
Before releasing the UI treatment, verify that:
- Partially charged is a billing status rather than a combined execution-and-payment label.
- The charged amount is visually primary and has an explicit currency.
- Every comparison amount is accurately labeled as requested, estimated, authorized, or another defined type.
- The uncharged difference is not presented as a refund, credit, waiver, or future collection without confirmation.
- Reasons come from event-level data, with Reason unavailable used when necessary.
- Final, pending, adjustable, and under-review states are distinguishable.
- Action instructions appear only when the workflow establishes what the user should do.
- Request IDs and related-event IDs support investigation and reconciliation.
- Amounts and terms remain consistent across activity details, invoices, and wallet or ledger records.
- Status meaning is available through text rather than color alone.
For teams moving from initial API validation to predictable production demand, clear usage and billing semantics are increasingly important. Token Forge Cloud provides Managed Model APIs for API-first model access and Private LLM Inference for private deployment and serving-layer control in enterprise AI workloads.
Contact Token Forge Cloud to discuss API access, private deployment, and LLM inference cost control.