Chargeback for New Relic

Which budget owner and which cost center each New Relic account bills to. This is the table that turns ingest into an invoice somebody can reconcile.

Every column sorts, including Flags, which orders the table by how much the account check found and puts the worst rows at the top. Sorting changes the order on screen only: the stored table keeps its own order, so saving after a sort does not rewrite every row for the audit trail to report. A blank sinks to the bottom either way, and account ids sort as numbers rather than as text.

Editing

Edit puts every cell in play at once, because this is a sheet rather than a form. Removing a row is staged like any other change: nothing is written until you press Save, and Cancel discards the lot by reloading.

Every field is required: Account ID, Account Name, Subaccount Group, Budget Owner, GBL and Cost Center.

The table as a file

Export CSV, in the Archive, writes the table as it stands now, one column per field.

Import CSV replaces every row from a file, and keeps a copy of what it replaced first, noted New chargeback file imported by whoever did it and when. That copy is the way back, and it is taken before anything is written.

A file has to carry exactly the columns of the current schema, no more and no fewer, and is refused otherwise: the refusal names what is missing and what does not belong. A file missing a column would silently blank it for every account, and one carrying an extra column was written against a different schema, where guessing which of its columns to keep is how a chargeback table stops matching the bill. Column order does not matter, since they are matched by name.

What is in the rows is reported rather than refused, the same way the account check reports rather than rejects. The table legitimately holds rows a stricter rule would throw out, so an import says how many fields came in blank, how many rows have no account id and how many account ids repeat, and leaves the judgement to you. Exporting the table and importing it straight back leaves it exactly as it was.

Row ids are not taken from a file. An imported table is a new table, and reusing whatever numbers a spreadsheet happened to hold would tie new rows to the history of old ones they have nothing to do with.

Archive

Archive opens every kept copy of the table, newest first, with who kept it, how many records it holds and the note it carries.

Copies are kept three ways. One is taken automatically before every save, noted Saved before edit with the date and who saved. One is taken automatically before every restore, noted Saved before restore the same way, so restoring the wrong copy is itself undoable. And you can keep one by hand at any time: type a note saying why it is worth keeping and press Save a copy. A note is required, because a list of copies distinguished only by their timestamps is a list nobody can choose from.

Restore this copy stays disabled until a copy is chosen from the list, then asks you to confirm, quoting that copy's note, who took it and how many records it will replace. Restoring keeps the current table first, under its own automatic note.

The copies taken by hand are kept for good. The automatic ones are capped at thirty, so an afternoon of editing cannot bury the copies somebody meant to keep.

The account check

Every row is compared against the accounts your API key can see, automatically, each time the page opens and again after a save. The table appears first and the flags land a moment later, so a New Relic that is slow or unreachable costs the flags rather than the page; the line above the table says which happened.

Red means the row cannot be billed as written; yellow means it is worth fixing but the charge still lands.

• no match, red. No New Relic account with that ID is visible to your key.
• Account name mismatch. The ID matches an account, but New Relic calls it something else.
• dash. The names match once dashes and spacing are normalized, which is the import artifact rather than a real disagreement.
• duplicate account ID. The same account appears on more than one row, so two owners could be billed for it.
• GBL missing or Budget Owner missing. The field is empty, so the charge has nowhere to land or nobody to receive it. A row missing both carries both chips. Only those two fields are flagged; a missing group is untidy but still billable.

It also reports how many live accounts have no row at all.

Nothing is rejected on the strength of a flag. A sub-allocation such as an Istio or EMEA line is deliberately not a New Relic account, and an account can be outside your key's scope while still being real. The check surfaces these; deciding is yours.

Creating an invoice

Pick a month, pick the accounts, give it a title, and generate. The month list offers only months with ingest recorded, and marks the current one as in progress, because billing a month that is still running would undercount it.

The invoice totals the month's ingest for those accounts at the rate set in Admin, and groups it by budget owner, since that is how it will be reconciled. It says so plainly when an account has no chargeback record, when a selected account reported nothing that month, and when no rate is set at all, rather than quietly leaving those out of the total.

Invoicing part of an account

An invoice normally bills whole accounts. To bill only part of one, tick Build from tags or a query beside the account picker. The box stays greyed out until it is ticked.

Once it is on, pick one or more accounts. The app then reads the last day of data in those accounts and lists the tags that data carries, which are the tags an entity has in New Relic, copied onto its records. Type in the filter to find one, tick a tag, and choose the values to bill, such as team = checkout. Choosing several tags bills only the data that matches all of them.

NRQL is the other way in, for admins only, since a query can read any record. Write what follows FROM and narrow it with WHERE, for example FROM Log WHERE service.name = 'checkout'. The invoice month is applied for you, and any SELECT or time range in the query is set aside and said so. Show 100 records displays a sample of what the query selects, from each account picked, so the data can be reviewed before billing it.

Generate reads a month of data from New Relic a day at a time, so it can take a few minutes for a large account. A card shows that it is working, with a progress bar, the time elapsed and what is being read, and Cancel stops it. The page can stay open while you work in another tab. A day New Relic cannot finish is tried again and split into smaller pieces, and one that still fails is named on the invoice, since it would make the bill low. The invoice states what was billed, and shows the total by data type and by account, and by the first tag chosen when billing by tags. The sizes are New Relic's bytecountestimate over the month, an estimate of what the data weighs and not New Relic's own bill.

New Relic keeps raw event data for about 8 days for most types and 30 for logs and metrics, so a month that has gone by may be only partly measurable. The invoice says so when that applies and shows the earliest data found for each account.

The saved invoices table has a Basis column that says whether an invoice was built from whole accounts or from a sub-query, and which kind. Hovering over a sub-query shows its tags or its query. Opening a saved sub-query invoice shows its stored figures, as for any saved invoice.

Saving an invoice

A saved invoice keeps its own figures, including the rate it was priced at. Recomputing from live data whenever it was opened would let a later change to the rate, or to a budget owner, quietly restate a bill that has already gone out. Saved invoices can be reopened, printed, downloaded and deleted; deleting one cannot be undone.

Download CSV, beside Print, saves the By account table as a spreadsheet: every account on the invoice with its budget owner, GBL, ingest in gigabytes and amount. The file is named for the invoice and its date, for example "Commerce 2026-10-11.csv", where the date is when the invoice was generated. The figures are plain numbers so a spreadsheet can add them up. An invoice with no price set states volume only, so its file has no amount column.

Audit trail

Every save, restore, add, delete and export is recorded with who did it and when, along with every invoice saved or deleted. It is append only, and the export is logged too, since a copy of this table leaving the app is itself worth knowing about.