Field notes

Prepaid commits in NetSuite without SuiteBilling

Practitioners described, and recommended, the same build for prepaid usage on NetSuite: a custom record that holds the balance and a scheduled script that bills from it. Here's how it works, where it drifts, and the checks it needs.

TrueUpp Research · Published 9 October 2026 · 7 min read

About these field notes. They draw on public discussions with RevOps, billing and NetSuite practitioners in October 2026, in which several people described how their teams run usage true-ups today. We paraphrase and don't name anyone. The worked examples are illustrations we built to show the mechanics, not any company's real figures.

The pattern

Teams selling prepaid commitments on NetSuite, without SuiteBilling, converge on roughly the same design:

1. A custom record per commitment holds the remaining prepaid balance, and often the rollover amount and expiry.
2. Usage arrives from outside NetSuite, typically a file exported from the product or warehouse each month, ideally at transaction level.
3. A scheduled script draws the usage down against the balance and posts a monthly invoice line for anything over.
4. Amendments are handled by closing the old commitment record and opening a new one with the new terms.

One practitioner called it cleaner than a spreadsheet, especially once rollover is capped. It's cheap, familiar and controllable, which is why it's common.

Where it drifts

1. The balance lives off the general ledger

One team noted that the remaining balance sits on the custom record, not in a GL account, until it's billed. Meanwhile the prepayment itself sits in deferred revenue. Two numbers describe the same money, and nothing forces them to agree.

2. Close-and-reopen splits history

Opening a new record for an amendment works, but the rollover carried across, the usage before and after, and the reason for the change now live on two records. Months later, explaining one invoice means stitching both together. (More in amendments.)

3. Aggregated postings lose the trail

Some teams post one aggregated line per period. Others keep usage at transaction level and compute the drawdown in the script. Practitioners preferred transaction level, because an aggregated journal can't show which usage consumed which credits.

4. The cap and expiry live in script logic

Capped, expiring rollover is the hardest part to get right in a script, and the least visible. If the cap's base or the expiry rule is wrong, the error repeats every month. (See 20% of what?)

Checks to run every month

1. Tie out each commitment's custom-record balance to deferred revenue for that customer, as above.
2. Reconcile usage counts between the source file and what the script consumed, per customer.
3. List lots expiring next month so expiry is applied on time and customers aren't surprised.
4. Review every amendment since the last close: is the carried balance equal to the old record's closing balance?
5. Recompute two or three contracts independently from the order form, outside the script.

The last check is the one most teams skip, and it's the one that catches logic errors rather than data errors.

When to move off the pattern

The custom record works well for a handful of contracts with similar terms. Signs it's time for more: more than one person maintaining the script, amendments every month, customers querying invoices, or an audit or fundraise asking for the trail behind usage revenue.