Working in Billing

Daily Operating Model

Billing works best when teams treat the module record as the source of truth and use tasks, tickets, workflows, and reports as supporting surfaces. The flows below are the common day-to-day paths to validate during setup and train users on after go-live.

Flow 1: Create a subscription plan

1. Open Billing and create the billing account or category if required.
2. Create a subscription plan with name, alias, interval, and active status.
3. Add subscription plan items with inventory product prices and quantities.
4. Review total amount and currency consistency across items.
5. Activate the plan when finance approves pricing.
6. Create a test subscription against a contact, user, or object record.
7. Generate the first cycle or invoice according to the billing process.
8. Verify the invoice lines match the plan items.

Flow 2: Issue and collect an invoice

1. Create or open an invoice generated from a subscription or direct billing action.
2. Review invoice items, due date, currency, recipient, and preferences.
3. Send or expose the invoice using the tenant billing process.
4. Customer pays through the configured provider or pay integration route.
5. Track payment attempts, logs, and provider response.
6. Mark partial payment, paid, overdue, invalidated, or refunded through controlled actions.
7. Confirm related wallet or transaction records update correctly.
8. Use workflow notifications for failed payments and overdue invoices.

Flow 3: Manage payment provider events

1. Configure the payment provider with credentials and webhook endpoint.
2. Run a low-value test payment to verify callback handling.
3. Review WebhookEvent and PaymentLog records for provider responses.
4. Investigate failed PaymentAttempt records before retrying.
5. Reconcile Payment and Transaction records against provider settlement reports.
6. Limit provider credential updates to administrators.
7. Create tasks for finance when a webhook cannot be matched to an invoice.
8. Keep provider-specific metadata on logs rather than changing invoice truth manually.

Flow 4: Operate wallets and balances

1. Open the customer or object billing context.
2. Review RecordBalance and RecordWallet values before applying a wallet transaction.
3. Create or adjust transactions only through approved billing actions.
4. Use wallet logs to audit balance movement.
5. Apply wallet credit to invoices according to tenant policy.
6. Investigate currency mismatches before posting.
7. Report wallet balances by record or customer segment.
8. Escalate negative or unexpected balances through finance workflow.

Day-To-Day Controls

• Start from the launchpad route, then use filters and saved views to focus on records needing action.
• Use status fields and lifecycle actions instead of free-text notes for important state changes.
• Attach documents, comments, or related records when a decision needs evidence.
• Create tasks when work leaves the current owner or needs a due date.
• Create tickets when the work is customer-facing or belongs in a support/service queue.
• Use workflows for predictable notifications, approvals, escalations, and cross-module updates.
• Use reports for recurring team reviews rather than exporting ad hoc lists every time.
• Keep permissions tight enough that users see the records they need but not sensitive configuration.
• Review rejected, cancelled, failed, or overdue records every week.
• Keep integrations aligned with the same lifecycle users follow in the UI.

Exception Handling

• If a record is stuck, check owner, status, required fields, approvals, and linked records before editing downstream data.
• If a workflow did not run, confirm the event name, trigger filter, record permissions, and service-user access.
• If reports look wrong, inspect whether the source record is draft, cancelled, archived, or missing a required dimension.
• If an integration created bad data, fix the source mapping and then repair the affected records through supported actions.
• If users cannot see a route, review launchpad access, module roles, page permissions, and tenant feature flags.
• If a public or embedded route exposes too much, disable exposure first and then correct permissions or filters.
• If two modules disagree, choose the module that owns the lifecycle as the source of truth and update the other from it.
• If a record supports audit, void, archive, or cancel it instead of deleting it whenever possible.

Reporting Rhythm

• Daily: review new, overdue, failed, rejected, and pending-approval records.
• Weekly: review owner workload, aging, status changes, and recurring exceptions.
• Monthly: review configuration, permissions, integration failures, and report definitions.
• Quarterly: review whether custom pages, workflows, and API access still match real operating practice.
• After major process changes: rerun one end-to-end flow with a pilot record before enabling it broadly.

Cross-Module Handoffs

• To Base objects: pass stable identifiers, owner, status, dates, and any dimensions required for reports.
• To tasks: include a precise action, due date, source record link, and escalation owner.
• To tickets: include requester, priority, support context, and the module record link.
• To workflows: prefer explicit create, update, approval, and status-change triggers.
• To reports: keep dimensions consistent across records so dashboards can group accurately.
• To integrations: use /reference/billing for namespace and intent details.