We've added 2 new resource types Orb's Data Exports.

1. Payment application
2. Payment attempt

These resources give you deeper visibility into the full payments lifecycle, from attempted charges (including retries through Orb's dunning process) to successful payments. Use these resources to better understand cash vs. AR, improve collections, and reconcile payments.

Learn more about data exports in our docs.

We're excited to announce support for non-zero cost basis allocations, enabling usage-based revenue recognition for recurring commitments and prepaid usage.

What's new
Previously, recurring commitments required using fixed fees with straight-lined revenue recognition—where a $12,000 annual commitment would be recognized as $1,000/month regardless of actual usage.

Now, you can assign a per-unit cost basis to allocations, allowing revenue to be recognized as credits are consumed rather than on a time-based schedule. This enables true usage-based accrual accounting for prepaid commitments.

Use cases
- Usage-based recognition: A customer commits to $100,000 for the year. Instead of recognizing $8,333/month on a fixed schedule, recognize revenue as they actually consume credits—even if usage is uneven throughout the year.
- Prepaid credits: A customer purchases 10,000 credits at $0.50/credit. Revenue is recognized proportionally as each credit is used, not straight-lined over time.
- Flexible pricing: Combine free promotional credits (zero cost basis) with paid allocations in the same plan.

How it works
When configuring an allocation price, you can now specify a `per_unit_cost_basis`:
- Free allocations: Set cost basis to $0 (default behavior)
- Paid allocations: Set cost basis to match the prepayment amount divided by the allocation quantity
- Revenue recognition: As credits are consumed, revenue is recognized proportionally—not straight-lined over time like a fixed fee

This gives you the flexibility to choose between time-based recognition (fixed fees) and usage-based recognition (non-zero cost basis allocations) depending on your business model and accounting needs.

Questions? Reach out to our support team or check the documentation for implementation details.

You can now enable a new account setting to display the plan name associated with each invoice in the customer portal.

When enabled:

• The invoice history table will include a new “Subscription” column.
• The unpaid invoice card and upcoming invoices sections will also display the plan name.

If the subscription has a name that is different than the plan name, the subscription name will be displayed.

You can now control automatic tax calculations at the customer level, giving you granular control over which customers have taxes automatically calculated on their invoices.

Customer-Level Tax Calculate Overrides

Previously, automatic tax calculation was configured at the account level and applied to all customers. With this update, you can now override the account-level setting for individual customers, providing more flexibility for complex billing scenarios.

The new automatic_tax_enabled setting on customers works as follows:

• true: Always calculate taxes automatically for this customer (regardless of account setting)
• false: Never calculate taxes automatically for this customer (regardless of account setting)
• null: Inherit the account-level automatic tax setting (default behavior)

Configuration Options

You can configure customer-level automatic tax settings through:

• Customer API: Use the automatic_tax_enabled field when creating or updating customers
• Orb Dashboard: Navigate to the customer's billing details section to modify their tax settings
• Bulk Operations: Update multiple customers programmatically via the API

When a customer has a specific tax setting configured, you'll see an "Override" label in the dashboard. When inheriting from the account setting, it will show "Account setting".

Use Cases

Gradual tax rollout: Enable automatic tax calculation for select customers during testing phases before rolling out to your entire customer base.

External tax use cases: When tax is handled in a separate system, this setting can ensure tax is skipped in Orb and not double taxing your customer.

The customer-level setting takes precedence over the account-level setting, ensuring you have complete control over tax calculation behavior for each customer relationship.

Orb now lets you create item-scoped credit blocks, giving you fine-grained control over how prepaid credits are applied across products and SKUs.

What’s new

• Item-level filters: Scope a credit block to specific items or SKUs directly from the UI or API to manage where credits apply.
• Hierarchical credit logic: Product-specific (filtered) credits are used first; when depleted, usage automatically draws from global (unfiltered) credits.
  
  

Why it matters

Item-scoped credits make it easier to allocate and track credit usage across products, while keeping configuration simple and invoices consistent. 

Availability

Item-scoped credit blocks are available in Early Access as Opt-in. If you are interested, please contact Orb support. 

Documentation

Learn more about configuration options, and behavior in our docs.

You can now analyze your revenue and billings data in Orb by prepaid credit block, credit note, and subscription plan.

• Pre-paid credit block: track credit consumption and expiration to understand revenue impact.
• Credit note: understand contra revenue lost to things like refunds, concessions, subscription changes.
• Subscription plan: compare revenue attributed to the plan a customer is subscribed to, inclusive of any subscription modifications like add-ons and overrides.

To try it out, head to the Recognized Revenue or Billings reports to filter and pivot your data. Learn more about reporting in our docs.

We’ve introduced a new invoice deferral option that lets you consolidate usage-based price changes on the next scheduled invoice, avoiding multiple invoices within the same billing period.

What’s new

• Deferred billing for usage-based prices: Mid-cycle price updates no longer trigger immediate invoices; you can now defer them to align with your customer’s normal billing cadence.
  
  
• Flexible configuration: Control deferral at the account level, during plan version migrations, or via the API using the can_defer_billing flag.
  
  
• Accurate service breakdowns: Deferred invoices clearly show separate line items for old and new prices (and discounts, when applicable).
  
  

Why it matters

This change keeps invoices predictable and consolidated for customers while maintaining full accuracy and visibility into rate changes.

Availability

Invoice deferral is available in early access for usage-based fees only.

Documentation

Learn more about configuration options and behavior examples in our docs.

We've added a dedicated Balance History page that gives you full visibility into how customer balances change over time.

What's new

• Transaction timeline: See all balance changes in chronological order with running balance calculations
• Rich details at a glance: View transaction amounts, types, creation dates, and associated invoices or credit blocks

Access the Balance History from any customer's detail page by clicking the new "View balance history" link in the Account Balance section.

We have introduced a new mark_as_paid field on the apply subscription changes API. This new field marks all payable invoices as finalized and paid, and works in tandem with the is_payable_now field that exists on changed resources (see: https://changelog.withorb.com/api-update-is_payable_now-field-added-to-changed_resources.created_invoices-3pIhZC).

The previously_collected_amount field is optional. If not provided, we assume the amount was correctly collected and simply mark invoices as paid without touching the customer balance.

When both mark_as_paid and previously_collected_amount are provided, we mark all payable invoices as paid and decrement customer balance by (previously_collected_amount - total amount due). This should only be used when the amount collected outside the system differs from the total amount due. Note that the total amount due includes tax calculations, while the amount shown for pending changes does not include taxes (see: https://docs.withorb.com/essentials/pending-changes for more info).

Any negative customer balance will be automatically reflected on the next invoice.

We’ve introduced a new field, is_payable_now, on changed_resources.created_invoices. The created_invoices field represents the list of invoices that will be generated as part of a pending subscription change or when previewing changes with the Include-Changed-Resources header. The new is_payable_now field on invoices represent ready-to-pay invoices containing only in-advance fixed fees. You can use this field to determine which invoices should be paid to enable access to a subscription change (eg. plan upgrade).

When it applies:

changed_resources (and thus created_invoices) are only returned

• When the explicit Include-Changed-Resources header is passed in a Subscription API request
• When calling the Pending Subscription Changes APIs