How to Track Game Asset Licenses, Receipts and Source Records Without Losing Them

Third-party assets save enormous amounts of production time. They also create a boring problem that becomes expensive only after the project has grown: where did this asset come from, what did we actually buy, and what evidence do we still have?

One downloaded prop is easy to remember. Fifty marketplace purchases across several stores, projects and contractors are not.

A useful asset record does not try to interpret the law for you. It simply preserves the facts you may need later: source, seller, purchase evidence, license reference, project usage and the questions that still need manual review.

This article describes a lightweight system that works for solo developers and small teams.

This is a recordkeeping workflow, not legal advice. A saved record does not prove that a particular use is permitted. Verify current official terms at the original source when the answer matters.

Start with one stable internal asset ID

Give every third-party asset a stable internal identifier.

For example:

EXT_FAB_ArcaneForge_001

or simply:

ASSET-0047

The exact format matters less than stability. The same identifier should connect the purchase record, receipt, project-usage note and any later review.

Do not make the ID depend on a filename that may change during production.

Record the exact product identity

At minimum, keep:

• exact asset or product name;
• marketplace or vendor;
• seller or publisher;
• product or listing ID when available;
• original product URL;
• date first accessed or purchased.

Why keep both the name and URL? Product names can change. Listings can disappear. A marketplace ID may remain useful even when the visible title changes.

If the asset is part of a bundle, record the bundle identity as well as the specific component you use.

Preserve purchase evidence without storing secrets

A good record should point to evidence, not contain sensitive payment data.

Useful fields include:

• purchase date;
• price paid and currency;
• order or receipt reference;
• location of the saved receipt or invoice;
• refund or replacement status if relevant.

Do not put passwords, full card numbers, CVV/PIN data, recovery codes, OTPs or private account credentials into a project spreadsheet.

A safe record might say:

Receipt: ProjectDocs/Purchases/Fab/order-2026-0042.pdf

That is enough to locate evidence without turning the asset tracker into a credential vault.

Save a license reference, not a guess

One of the most useful fields is simply:

License reference

Record the license name exactly as the vendor shows it and the official URL or saved document you relied on.

Then separate factual fields from interpretation:

• license name;
• official terms URL;
• saved copy location if you archive one;
• attribution requirement shown by the source;
• redistribution restriction shown by the source;
• AI/generated-content disclosure information when relevant;
• unresolved questions.

If you do not know the answer, write Needs review instead of inventing one.

That small habit is much safer than converting uncertainty into a confident checkbox.

Track project usage separately from the purchase

An asset can be purchased once and used in several projects. Do not duplicate the whole purchase record every time.

Keep a separate usage table with fields such as:

• internal asset ID;
• project name;
• first build/version using the asset;
• usage type: prototype, production, marketing, client work;
• whether the asset was modified;
• modification reference;
• attribution location if required;
• current usage status.

This makes an important distinction: what you bought is one record; where you use it is another.

That distinction becomes especially helpful during source-file handoff, publisher review or project archiving.

Record modifications without pretending they change the license

If you edit a texture, combine meshes or create a derivative version, record the production change.

For example:

Modified: yes

Modification reference: Assets/Environment/Forge/Source/ArcaneForge_Custom.blend

This tells the team where the changed version came from.

It does not answer whether the modification changes what the license allows. Keep the production record and the licensing question separate.

Add a review date for long-lived projects

Terms, URLs and product pages can change.

For a project that will ship months or years later, add:

• last manually reviewed date;
• reviewer;
• review result;
• next review date when one is useful.

You do not need to re-read every license every week. Review is most useful around meaningful events:

• before commercial release;
• before giving source files to another company;
• when moving an asset into a new project;
• when a marketplace changes its terms;
• when the original listing disappears;
• when an unresolved question affects production.

Keep a small release/handoff gate

Before release or source-file handoff, check whether:

1. the original source can still be identified;
2. purchase evidence can be found;
3. the license reference is recorded;
4. project usage points to the correct internal asset ID;
5. attribution questions are resolved where relevant;
6. redistribution/source-sharing questions are resolved where relevant;
7. a backup exists with the project documentation.

The purpose is not paperwork for its own sake. It is preventing a late-stage question from turning into several hours of searching old email, browser history and marketplace accounts.

Example record

A compact row might look like this:

The row is useful because it points to evidence and uncertainty instead of pretending to replace the original terms.

Do not turn the tracker into a legal database

A small team usually needs operational clarity more than an enormous compliance system.

Avoid fields that no one will maintain. Keep the record focused on questions you can answer reliably:

• What is it?
• Where did it come from?
• Who sold it?
• When did we obtain it?
• Where is the receipt?
• What license reference did we rely on?
• Which project uses it?
• What changed?
• What still needs review?

That is already enough to make future investigation dramatically easier.

Use a free checklist for single assets

If you only need to document occasional purchases, a simple printable checklist is enough. The Knit of Shadows itch.io page includes free/pay-what-you-want recordkeeping checklists alongside the larger production systems.

For a growing asset library, the Indie Game Asset License & Source Tracker adds multi-asset records, project usage, receipt indexing, a review queue and dashboard in one editable workbook.

You can also use the free game-development tools hub for related asset-planning and production utilities.

The useful outcome is traceability

Perfect records are not the goal.

The goal is to make it possible for your future self—or another person on the project—to answer:

“What is this asset, where did it come from, what evidence do we have, and what still needs checking?”

If your record can answer that in a minute instead of an afternoon, it is doing its job.