Why the native invoice does not answer 'what did Project X cost?'
The DigitalOcean monthly invoice rolls up by SKU (Droplets, Volumes, Spaces) but does not group by Project, tag, or any customer-defined dimension. The Projects feature in the dashboard groups resources visually but does not publish a per-project cost line. The information needed to allocate is there, but the rollup is not.
The three signals you can combine
Strong: cost-allocation tags applied at resource creation. Medium: DigitalOcean Projects assignment (because every resource lives in exactly one Project). Weak: resource name conventions (e.g. an 'acme-prod-web-1' Droplet probably belongs to the acme project).
- Tag every resource with project:<slug> when it is created.
- Use DigitalOcean Projects to group at the cloud layer for a fallback signal.
- Standardize resource naming so legacy resources still allocate cleanly.
Pulling per-resource usage from the DO billing API
Download the invoice CSV via GET /v2/customers/my/invoices/{invoice_uuid}/csv. Each row has name, category, description, amount, start, project_name, and tags (in DO's key:value format). Combined with the resource API, this is enough to attribute every line to a project.
Mapping legacy Droplets that pre-date your Projects layout
Resources created before you adopted Projects often land in the default Project with no helpful tags. Allocate them with a name-pattern rule (`web-prod-*` → acme-prod) or with an account-level rule when an entire team owns a team-id.
Sanity-checking against the monthly invoice
Sum the per-project rollup; it should match the DO invoice total within rounding. If it doesn't, the gap is usually an SKU that wasn't ingested or a credit that was applied at the invoice level rather than per-line.
Who tovin.io is for
Frequently asked
Does the DO Projects feature show cost per project?
It groups resources visually but does not publish a per-project cost view on the invoice. You need a tool or script to combine Projects, tags, and billing data.
What tag key should I standardize on?
`project:<slug>` is the lowest-friction default. Pair it with `environment` and `owner` for finer-grained rollups.
What about Droplets that two projects share?
Keep them in a `shared:<service>` bucket and allocate by a usage driver (requests, storage, seats) rather than splitting evenly.