If you’ve read our article on the Royalty Account Base for sales, you already know that the when of royalty accounting is a deliberate choice — not something that just happens automatically. Costs and recoupables work differently from sales, but the underlying idea is the same: you are in control of when they land in a royalty period, as long as you understand the logic.
Here’s how it works.
Costs don’t follow the Account Base
The Account Base setting (Sales Period, Invoice Date, Payment Period) on a Royalty Account applies to sales only.
Costs follow their own set of rules, which are based on how you enter or import them — not on invoice or payment dates.
This means two things worth noting upfront: the invoice date and payment date fields on a cost document have no effect on royalty accounting. They’re useful for internal bookkeeping and profit reporting, but details ignores them when assigning a cost to a royalty period.
What matters is how the cost date is handled at the point of entry.
Costs and recoupables — what’s the difference?
In details, costs are expenses you’ve entered in the system — production costs, advances, marketing spend, and so on. A cost becomes a recoupable once it has been accounted against a royalty contract, meaning it will be set off against the royalties owed to that payee.
The royalty period logic described in this article applies to costs at the point of entry into the system — before the recoupable step. Once a cost is accounted as a recoupable on a contract, it carries the royalty date assigned at entry into the royalty statement.
How details determines the royalty date for costs
Option 1 — Costs entered manually
When you enter a cost directly in details — an advance payment, a production cost, a sync fee received — you set a specific date on that line. That date is what details uses as the royalty date. Whatever month you enter, that’s the period it will be recouped in.
This is the most direct form of control: you decide the date, details uses it.
Option 2 — Per line dates in a cost import (System Date)
If you import costs via file upload and the file contains a date per row, importing it as System Date means each line carries its own royalty date. Lines within the same import can land in different royalty periods, which gives you the most granular control for batch insertions.
This is useful when you’re importing a batch of costs that span different periods and want each one to land exactly where it belongs.
If you want to import a date column for reference only — without it affecting royalty accounting — choose “Document Date (info only)” or “Payment Date (info only)” when mapping the import. The date is stored on the line and visible in the system, but details ignores it for royalty purposes.
Option 3 — No date imported (import month default)
If no System Date is imported, details uses the month of the import as the cost date for every line in that batch. An import done in tile 1 applies as January costs, tile 3 as March costs, and so on.
This is the simplest approach and works well for regular, recurring cost imports where the period is obvious from the timing of the import itself.
One more degree of control: overriding the date at recoupment
All of the above determines the royalty date at the point a cost enters the system — either manually or via import. But details gives you one additional opportunity to adjust: when you process recoupables.
In ROYALTY / RECOUPABLES, when you account costs as recoupables against a contract, you can choose a different recoupment date — overriding whatever date was originally assigned to the cost. This is useful when, for example, you want to hold a cost back to a later period or align a batch of recoupables to a specific statement cycle, regardless of when the underlying costs were entered or imported.
This override happens at the recoupment step only. It doesn’t change the original cost date stored on the line — it only affects which period the recoupable is applied to in the statement.
The same logic applies to recoupable income
Costs are the most common item set off against royalties — but details also supports the inverse: additional income that is treated like a recoupable credit.
This covers situations where you receive income that needs to be attributed to a payee — a sponsoring, a grant, or a sync fee, for example. That income is credited against their royalty balance in the same way a cost would be debited.
In details, this is handled as a negative recoupable — and it follows exactly the same royalty period logic as costs. The same rules apply: the date entered manually, the System Date per line, the import month default, and the same forward-shifting behaviour if a statement has already been processed for that payee.
Costs won’t get lost in the past
Here’s the rule that matters most in day-to-day work:
If a royalty statement has already been processed for a payee, that period is locked and won’t accept new recoupables for this specific account. Rather than letting costs disappear unrecouped into a period that’s already closed, details automatically shifts their royalty date forward to the next open period for that payee.
This applies whenever you’re importing costs into a period that already has a statement for a specific payee — even a test run.
A few practical examples of what this means:
- You import costs dated March, but a Q1 statement has already been calculated for a payee → those costs move to April 1st, into the next available period.
- You import costs into a past tile → same rule, during the recoupment process details finds the next open period and applies the costs there.
This behaviour is per royalty account. A single cost import could land in March for most payees, but in April for one payee whose Q1 statement was already calculated — even in test mode.
If you want costs to land in March for everyone: make sure no statement has been run for March, Q1, or S1 for any payee before the import. This includes test calculations.
Why this design makes sense
The logic above exists to protect your statements. Once a royalty period is closed for a payee, the numbers shouldn’t change retroactively — that would mean reissuing statements, creating confusion, and potentially triggering disputes. By pushing new costs and recoupables to the next open period, details keeps past statements clean and stable.
It also means you don’t need to be perfectly organised about the order in which you do things. You can import costs at any time; details will place them correctly based on what’s already been processed.
Quick reference
| Scenario |
What happens |
| Cost entered manually |
Uses the date entered on the line |
| System Date imported per line |
Each line uses its own imported date |
| No System Date imported |
All lines use the month of the import |
| Recoupment date in RECOUPABLES |
Overrides the original cost date for that recoupable |
| Period already has a statement for payee |
Cost / recoupable pushed to next open period (per payee) |
| Cost invoice date or payment date |
No effect on royalty accounting |
| Other income (negative recoupable) |
Same logic as costs |
One practical tip
If you’re doing test runs of statements during setup — which is perfectly reasonable — be aware that even test calculations count as “processed” from details’ perspective. Any cost imports you do after a test run will be pushed to the next period for the affected payees. That’s usually not a problem, but worth knowing before you start.
If you have a complex cost import coming up and you’re not sure how it will be handled, reach out. The details team can help you map the import correctly before anything lands in the wrong period.
Get in touch with the details team →
This article is part of a series on royalty accounting in details.
Previous: When Do Sales Get Reported? Understanding Account Base
