Tracking credits per client, per deliverable

Most people running client work on Versely know their total credit spend for the month and nothing else. That single number is enough to tell you whether the plan is right and useless for the question that actually decides whether the business works: which client ate the credits.

The answer is almost never the one you expect. The client generating the most volume is usually not the expensive one. The expensive one is the client whose third revision round quietly regenerates the whole deliverable, and whose quote was written as if there would be one round.

The five phases that consume credits

A deliverable is not one charge. It is five, and four of them are invisible in a monthly total.

Phase	What it is	Typically counted?
Draft	The first pass at each shot	Yes
Reroll	Regenerating shots that came back wrong	Rarely
Preview pass	Iterating on the cut in the editor	Free at 480p, with a short per-user cooldown
Revision regeneration	New or replaced shots after client notes	Almost never
Final export	The confirmed render off the timeline	Yes, once

Two of those rows do most of the damage. Rerolls are the shots you threw away, and their rate varies enormously by model, prompt and shot type; there is a full treatment of reroll rates and budgeting against the shots you discard. Revision regeneration is worse, because it looks like editing and behaves like production. A note that reads "can we try it without the character walking" is not an edit. It is a new generation with the credit profile of a draft.

The preview row is the one piece of good news. The editor is EDL-based, so the cut lives on one timeline and preview: true renders a free 480p pass, subject to a short per-user cooldown, which means pacing and ordering arguments do not consume credits at all. The final export is charged once regardless of how many clips are on the timeline. The billing mechanics are laid out in previews and the final export, and they are the reason a revision policy built around preview rounds is cheap while one built around re-exports is not.

The sheet

One row per credit-consuming event. Not one row per deliverable, and not one row per day, because the whole point is being able to sum along two different axes.

Column	Contents	Why it exists
date	ISO date	Lets you slice by month without a pivot
client	Short code, e.g. ACME	The axis you will actually rank on
deliverable	ACME-2608-01	Client, year-month, sequence
phase	draft / reroll / preview / revision / export	The five rows above
round	0 for internal, 1+ for client rounds	Distinguishes your rerolls from their notes
step	Model or tool used	Shows which shot type is expensive
est_credits	Pre-dispatch estimate	Your quoting input
actual_credits	What was charged	Your reality input
billable	included / overrun / write-off	Feeds the overrun invoice

Three conventions make the sheet worth keeping rather than a chore you abandon in week three.

Deliverable IDs are assigned at quote time, not at production time. If the ID does not exist before you generate anything, you will not backfill it, and the sheet becomes a list of unattributed charges.

Round 0 is yours. Everything before the client sees anything is round 0, including every reroll you did because the first take was bad. That separation is the single most useful thing in the sheet, because it tells you whether your credits are going to your own quality bar or to the client's notes, and those two problems have completely different fixes.

Estimate and actual are both recorded. The gap between them is your quoting error, and you cannot improve a quote whose error you have never measured.

Filling it without turning it into a second job

The estimate column is the easy one. Ask for a cost estimate before dispatching a batch and you get per-item and total credits from the same pricing logic that does the real charging, alongside your balance. Checking credits before generating is the pre-flight version of the same thing for a long multi-step run. The distinction between the two, and when each one earns its keep, is covered in estimating credit cost before you dispatch a batch.

The actual column needs a discipline rather than a tool: log at the end of each batch block, not per generation. One line in the sheet after each work session, summing that session's charges by phase. Per-generation logging is accurate and nobody does it twice.

Attribution is where a project structure pays for itself. Keeping each client's generations in their own named project means that when the sheet and the account disagree, you have a list to reconcile against rather than a scroll through a mixed library. Duplicate URLs are skipped when you save, so re-saving a batch to catch stragglers is safe.

Quoting so the number survives three rounds

Here is the arithmetic the ledger exists to feed. The numbers below are illustrative shapes, not real per-model figures — pull your own from your history, and read your plan's credit rate off the credits page when you convert to money.

Take a deliverable that needs six accepted shots.

1. Accepted shots: 6.
2. Reroll multiplier: if your history says you keep two of every three takes, you are generating 9 to get 6. Multiplier 1.5.
3. Round 0 total: 9 shots' worth of credits, plus one export.
4. Revision reserve: assume each client round replaces 20% of shots. Three rounds at 20% of 6 is roughly 4 additional shots, plus their own reroll multiplier, so call it 6.
5. Quoted credit basis: 9 + 6 = 15 shots and one export, not 6 shots.

The quote you write is the round-0 number plus the reserve. If you quoted the round-0 number alone, three rounds of notes cost you two-thirds again on top, and that is the entire mechanism by which a profitable-looking client is not. The pricing side of this, including where usage rights and package discounts sit, is worked through in how to price AI video services as an agency.

Note what the reserve is not. It is not padding, and it is not something you hide. It is the reason your quote can include a stated number of revision rounds without you flinching at round three.

The monthly unprofitable-client check

Fifteen minutes, once a month, on the same day you do invoicing.

1. Sum actual credits by client for the month.
2. Divide by what you invoiced that client. You now have credits consumed per unit of revenue, in whatever currency you bill.
3. Rank every client on that ratio. Not on total credits, not on revenue. On the ratio.
4. Take the median. Anything above roughly twice the median is the flag.
5. Read the phase split for every flagged client. This is the diagnosis step, and there are only three real answers.

The three answers, and what each one means:

• Round 0 dominates. Your production is inefficient on this client's format, usually because a specific shot type rerolls badly. Fix the prompt or change the model for that shot. This is your problem and it is cheap to fix.
• Rounds 1–3 dominate. The brief is not landing. The client is not unreasonable; they are describing what they want after seeing it rather than before, which is a briefing failure upstream of production.
• Round 4+ exists at all. You have no revision cap, or you have one and are not enforcing it. This is a contract problem, not a production problem.

Then act, in this order: fix the prompt, fix the brief, reprice at renewal, and only then have the conversation about whether the account continues. Most flagged clients are fixable at step one or two, and the ones that are not tend to declare themselves within two months.

Keep the ratio internal. It is a production diagnostic, not something that belongs in a client-facing report. If a client genuinely wants to understand the unit, credits explained for budgeting is the primer to send them.

FAQ

Why track in credits rather than in money?

Because credits are the unit that actually varies with production decisions, and money is a conversion applied at the end. A ledger in credits stays valid when you change plans, and it lets you compare a shot type against another shot type without a currency step in between. Convert once, at the monthly check.

Do preview passes belong in the sheet if they are free?

Yes, as a count rather than a credit figure. Preview count per deliverable is the best early indicator you have of a brief that is not landing, and it costs nothing to record. A deliverable at fourteen preview passes and two client rounds is telling you something different from one at three previews and five rounds.

How do I attribute a batch that served two clients?

Split it at logging time by output count, and if that is genuinely ambiguous, stop batching across clients. Cross-client batches save a few minutes of setup and destroy the only number the sheet exists to produce.

What if my history is not long enough to know my reroll multiplier?

Use 1.5 for the first month and measure. Almost nobody keeps every take, and almost nobody rerolls more than half, so 1.5 is a defensible starting assumption. Replace it with your real figure as soon as you have four weeks of round-0 rows.