Skip to main content
Beta.
By default, TextQL bills your whole organization as a single line. Chargeback lets an admin split that bill across internal teams instead — engineering, sales, a business unit, whatever your org’s structure is — each configured as its own bill line, with membership that keeps itself up to date as your org changes and historical splits that never shift after the fact. Read Usage first if you haven’t — Chargeback assigns the same underlying usage rows that page explains how to read.

Overview

Chargeback lives in two places in the Console:
  • Chargeback — where you define bill lines and their membership rules, resolve anyone who doesn’t cleanly fit one, and export the committed statement as CSV
  • Usage, in its Bill Line stacking mode — where you see the resulting split charted over time, replay what an older configuration would have produced, and export that chart as CSV
Access follows the same check as the rest of the Console: any org admin already has it, nothing extra to grant.

Bill Lines

A bill line is a named split of your bill, defined by one or more rules. A rule can match:
  • an entire workspace (org)
  • specific teams or roles within a workspace
  • a role name matched across every workspace
Rules OR together — a person is on a line if they match any one of its rules. Each org-and-member pair a line’s rules put on it is an assignment, and carries a weight between 0 and 1, so one person’s usage can be split across more than one line for people who genuinely work across teams. Being assigned isn’t the same as being billed: a line can have far more people assigned to it than it actually bills in a given period — assigned people with no usage that period cost nothing. A “500 assigned, 90 billed” line just means 410 of those people didn’t use TextQL that period.

Rosters Update Themselves

You don’t maintain bill-line membership by hand. Chargeback reads TextQL’s own member and team data directly — there’s no external HRIS to connect. When someone is hired, offboarded, or changes role, that change is queued, and a background process recomputes which bill line(s) their rules now put them on and applies only the difference. Every automatic change lands in a roster event log, kept separate from your actual configuration history, so you can see exactly when and why someone’s assignment moved. If you manually remove someone from a line they’d otherwise match — an exclusion — that removal sticks, even if they later leave and are rehired.

Resolving Ambiguity

Not everyone reconciles cleanly, but only one of these reasons actually needs your input; the rest are informational and clear themselves once a later configuration or team change covers them: The same queue also surfaces a line-level flag, not a person-level one: Resolving an Ambiguous flag applies immediately — it doesn’t create a new configuration version, so it shows up in the roster event log rather than as a rule change. The other reasons are read-only status, not a to-do list: there’s no button for them, and the row disappears on its own once the underlying condition is gone.

Frozen Billing Periods

Your bill-line configuration has its own version history, browsable from the History control on the Chargeback page. Committing a change closes out the previous version and opens a new one, but a past billing period always re-derives from whichever rules were actually active at the time — never from your current rules. Changing your bill lines today never rewrites what an earlier period looked like. There’s one deliberate exception: your very first commit is backdated to cover all pre-existing usage. That backdated roster is a snapshot of who’s assigned as of the first commit, not a reconstruction of who was actually on each team back when the older usage happened, so anyone who was offboarded, changed teams, or moved workspaces before you ever set up Chargeback won’t be in it, and their pre-existing usage stays Unallocated unless you add them to the commit manually. Only the first commit backdates at all — every commit after it follows the normal rule above.

What-If Previews

Two different things both get called a “preview,” and only one of them handles a hypothetical rule you haven’t saved yet:
  • An unsaved rule change can only be dry-run from the Chargeback editor itself, against a real period — it shows the resulting member count, ACU, and dollar impact per line, but only as totals, not a chart.
  • A past, already-committed configuration can be replayed on the Usage page as a full chart over any time window. It can’t replay something you haven’t saved — only real history, not a hypothetical.

CSV Export

There are two different exports, from two different pages:
  • Chargeback’s own Export CSV — exports the committed chargeback statement for whichever period is currently selected (yesterday, 30 days, 90 days, or a custom range): a per-line summary plus per-member detail, filename chargeback_{start}_to_{end}.csv. Getting the per-member detail requires a live fetch per bill line at export time — if that fetch fails, you still get the file, just with the summary only, and a toast telling you so.
  • Usage page’s Download CSV — exports whatever chart view is currently on screen: one row per time bucket, an ACU and dollar column pair per bill line (or whatever else the chart is stacked by), plus running totals. This one is built entirely from what’s already loaded in the chart.

Cost Center vs. Bill Line

Chargeback assigns usage to a bill line. It does not set the separate Cost Center tag that shows up on individual usage rows (covered in Usage) — that’s an independent attribute that already exists on the underlying data. You can break a single bill line’s usage down by cost center, but changing your bill lines never changes anyone’s cost center, and changing cost centers never changes anyone’s bill line.

Need Help?

Contact support@textql.com.