Read quota and credit evidence before committing spend.
Billing is organization-owned. The overview reports the current plan and quota use; Credits exposes lots, reservations, and an append-only ledger; Payments records manual bank or invoice references against active prepaid offers.
Open the organization billing views
Permission
is required to create a payment reference and access billing mutations. Read access to Overview, Payments, Credits, or their evidence may also be restricted by your effective role.
The Billing settings group contains Overview, Payments, and Credits. If the group or a leaf is absent, ask an organization Owner or role manager to review the exact role version assigned to you.
Review plan and quota state
- Confirm the plan.Use the displayed organization plan as the context for the balances and limits below it.
- Review available credits.Compare total or usable balance with reservations and dated lots in Credits before assuming all issued credits can be spent immediately.
- Inspect each quota meter.The interface provides both numeric values and accessible explanatory text. Do not rely on color alone.
- Act on warnings early.Warning thresholds identify approaching limits; a hard enforcement response can occur later when a request would exceed the authoritative limit.
- Refresh after commerce changes.A newly recorded payment reference is Pending and does not itself prove that credits were issued.
Success state
You can identify the current plan, usable credit position, consumed and remaining quota for each reported resource, and whether follow-up is needed before more usage.
A meter is a readable snapshot. Every resource-creating operation still performs its own current entitlement and quota check.
Record a manual payment reference
Permission and security
and a recent passkey, security-key, authenticator, or recovery-code verification are required.
- Select an active prepaid offer.Review the exact included credits, validity period, and displayed price. If no active offer is available, the form cannot create a reference.
- Enter the bank or invoice reference.Use the reference associated with the external payment arrangement. This is evidence for reconciliation, not a card number.
- Verify identity.If prompted, follow Verify identity, complete the fresh security check, and return to the form.
- Record payment reference.Confirm the offer and reference. The request creates an immutable payment record in Pending state.
- Inspect state history.Return to Payments and open the record to see each immutable state change. Do not treat Pending as settled or credited.
Success state
The Payments inventory shows the new reference, selected offer, Pending state, and initial immutable history entry.
This workflow only records a manual bank or invoice reference. Payment verification and any later credit issuance are separate events.
Trace credits and reservations
- Credit lot
- A dated issuance with its own original amount, remaining amount, validity, and state. Lots let you distinguish aggregate balance from the credits that can actually be consumed.
- Reservation
- An amount held for a bounded operation. Reserved credits are not simultaneously available for unrelated usage.
- Ledger entry
- An append-only debit, credit, reservation, release, or adjustment record. Earlier entries are never edited to make the current balance appear simpler.
- Start with lots.Identify active and expired or depleted issuances and their remaining amounts.
- Review reservations.Match active holds to their operation or resource before diagnosing an apparently lower usable balance.
- Follow the ledger.Load older entries and reconcile the sequence of issued, reserved, consumed, released, or adjusted amounts.
- Compare with Overview.The summary balance should be understood as the result of this evidence, not as a replacement for it.
Success state
You can explain the displayed balance from immutable lots, reservations, and ledger events and identify whether a discrepancy is pending settlement, an active hold, expiry, or consumption.
Plan around validated limits
The plan and quota values displayed in your organization remain authoritative. The following are concrete input constraints enforced by the current user interface, independent of plan size.
| Workflow | Current constraint | What to do |
|---|---|---|
| Account password | At least 15 characters; common and breached values rejected. | Use a unique passphrase and password manager. |
| Private group Chat | 2-100 selected members. | Use a team or organization channel for a broader durable audience. |
| Chat message | Up to 10,000 bytes. | Move long-lived material to Knowledge and link it. |
| Manual time cell | 1-1,440 minutes; note up to 2,000 characters. | Split records when they represent distinct intervals or work. |
| Repository credential | Expiry from 1 to 365 days. | Choose the shortest practical expiry and revoke when unused. |
| Package credential | Expiry from 1 to 8,760 hours. | Limit package rule and scopes as well as duration. |
| Browser file edit | UTF-8 branch content; files over 1 MiB use clone instead. | Edit binary or large files through Git tooling. |
| Repository import | Verified Git .bundle containing refs/heads/main. | Create the bundle locally; URL mirroring is not the import path. |
| Webhook destination | Public HTTPS URL; literal IP destinations rejected. | Use a stable HTTPS hostname. |
| Merge bypass reason | 8-2,000 characters when bypass is allowed. | State the concrete incident or exception; evidence is audited. |
| Member invitation | Expires after seven days. | Revoke and issue another if acceptance misses the window. |
These interface limits describe the current release and can evolve. For capacity decisions, use the numeric limits shown in your organization's Billing Overview at the time of the operation.
Know what Billing does not do
- Mozaic does not collect or charge a payment card in the payment-reference form.
- Recording a reference does not mark the payment settled and does not issue credits immediately.
- The user interface selects from active prepaid offers; it does not create or edit the commercial offer catalog.
- Ledger and payment history are evidence surfaces. Existing entries are not rewritten or deleted from the normal workflow.
- Quota warnings do not reserve capacity. A later request can still fail if other activity consumes the remaining allowance first.
- One-time secrets in repository, package, webhook, invitation, and recovery workflows are not recoverable after dismissal; issue or rotate a replacement.
Common billing and limit failures
Billing is absent or Access denied appears
Your effective role lacks the required billing claim or the organization capability is unavailable. Ask an Owner or role manager to inspect your exact role version; switching browser appearance or workspace does not change server authorization.
No prepaid offer is available
There is no active eligible offer for the organization. The reference form cannot invent one. Wait for an offer to become active or use the commercial support path provided to your organization.
Fresh authentication required
The security window expired. Follow Verify identity, complete a passkey or authenticator check, and return to the same New payment route before submitting again.
The payment stays Pending
Pending is the expected initial state for a recorded reference. Check immutable state history for reconciliation progress; do not submit duplicate references merely to force a state change.
Usable credits are lower than issued credits
Inspect expired or depleted lots and active reservations, then follow ledger debits. Issued total, remaining total, and currently usable total are different measures.
A resource action says a quota is exceeded
Reload Billing Overview and compare current usage with the authoritative limit. Complete, cancel, archive, or remove eligible resource usage only through its normal lifecycle; a warning meter cannot override enforcement.