# Economics Provider Collection > Collect and reconcile Pollinations Economics vendor balances, monthly usage, invoices, and provider evidence using the best available API, CLI, MCP, or authenticated dashboard. - Skill: `pollinations/economics-provider-collection` (Agent Skill, multi-file: 45 files) - Install (CLI): `npx skillmds@latest add pollinations/economics-provider-collection` - Raw SKILL.md: https://api.skillmd.com/api/skills/pollinations/economics-provider-collection/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: pollinations (https://skillmd.com/u/pollinations) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/pollinations/economics-provider-collection --- # Economics provider collection Use this skill when the user asks to refresh vendor data, inspect provider accounts, prepare a monthly close, or reconcile provider cost with Pollen. ## Source of truth Read `operations/economics/provider-registry.json` first. - The registry owns canonical vendor IDs, aliases, account lifecycles, active monthly-review status, balance-tracking decisions, access URLs, and workspace domains. It is also the only vendor list: every bank or Runway counterparty is registered with its business `category` (`compute`, `infrastructure`, `development`, `operations`, `revenue_share`, `office`, `admin`, `payroll`), optional `cashRules` (bank-description rules for mixed vendors) and `runwayLine`. A new vendor in a bank statement needs a registry entry before its cash can be categorized. - Active vendors have `monthlyReview: true`. Refresh only those during a normal monthly run. - Inactive vendors remain visible for history. Inspect them only when the user asks or when they are deliberately reactivated. - Never infer aliases, accounts, models, or funding from similar names. Then read only the requested vendor guide in `references/providers/.md`. The registry's `connector` field gives the filename. Dots in vendor IDs use dashes when the registry says so. ## Collection order Choose the first source that supplies authoritative, sufficiently granular data: 1. Supported provider API. 2. Supported CLI. 3. Available MCP or authenticated connector. 4. Provider dashboard. Do not build a permanent provider integration for a bounded monthly task. Run the documented command or use the dashboard directly. For dashboard collection, group registry access targets by `workspace`. Open all URLs for one workspace together. First enumerate the connected browser windows, then use only the window whose visible email and organization match the registry target. Stop if the match is ambiguous. Never store browser-window IDs or copy cookies, passwords, session tokens, or credential-reveal URLs. Use only existing authorized credentials. Creating, rotating, synchronizing, or deploying a credential is outside collection and requires the repository's separate secret-mutation plan and explicit scoped approval. ## Monthly result For each active vendor and each active account, collect: - the current cash/prepaid and promotional-credit balance when `balanceTracking` is true; - the last completed UTC calendar month's usage at the deepest source-backed grain available: model, GPU instance/workload, service/SKU, then provider total; - the invoice, statement, receipt, or provider export that proves the billed obligation or confirms that no payment was due. Store one balance snapshot per canonical account. Multiple grant lots use the same checked timestamp and distinct resource IDs (`current-balance-lot`), not an additional account-total row. A snapshot collected during the current calendar month closes the previous month; do not require repeated checks during that same close cycle. Account aliases only collapse IDs that are explicitly listed in the registry. Keep provider usage, provider balance, and bank payment as separate facts. A top-up is not usage. An invoice date is not automatically the usage month. A balance snapshot is current state, not historical burn. - Usage `start`/`end`: actual UTC coverage, end-exclusive; never replace billing cycle dates with calendar-month boundaries or use collection time as coverage. - Credit snapshot `end`: verified expiry. Blank means unknown, not unlimited. Use `resource_sku: current-balance-no-expiry` only with verified non-expiring terms. Recheck omitted/changed terms; never silently extend old credits. A user-approved forecast exception uses `current-balance-expiry-assumed`, empty `end`, and the scoped approval in evidence; it is not verified terms. - Stripe: record `coverage_end` and `expected_accounts` for each account-month; partial exports must not become a completed forecast baseline at rollover. If model or GPU detail is unavailable, preserve the exact provider total and state the missing granularity. Never allocate a total using an internal model name or an undocumented ratio. ## Evidence and ledgers - `` means a private, task-specific directory outside Git. Keep temporary originals under `evidence/`; do not recreate `ingest/data`. Retain source files in Drive and a resumable upload manifest before removing scratch. A screenshot must show the loaded value, account and selected period; a loading screen or another account's page is not evidence. - Amounts live in the ledger, never in a connector guide. This repository is public: a guide records how to reach a number (route, URL, command, which column, which convention), and the ledger row carries the number itself with its evidence link. Do not paste balances, grants, invoice totals, spend, or invoice numbers with amounts into `references/`. - Upload each new invoice/export to the accounting Google Drive immediately after download; verify it there before continuing to the next provider. Layout, file naming, month folder IDs, and the coverage check are in `references/drive-archive.md`. - `economics_vendor_ledger` stores provider balances and usage facts. Usage is negative `paid`/`credit`; a billing refund is positive `paid`. Grants and balance snapshots are positive, not usage. `source` names the collection method (`api`, `cli`, `export`, `invoice`, `dashboard`), not the billing portal. Preserve signed amounts when fixing a classification. - `economics_bank_ledger` stores Wise-backed cash movements and their evidence. Prefix new/reviewed evidence with `evidence_type=supplier_document` or `evidence_type=payment_statement`. A statement proves payment, not a supplier invoice. Add `evidence_requirement=payment` only after reviewing that exact fact as payment-only (e.g. cashback/payout). Folders/forms are not documents. Preserve existing lost-document exceptions. Link the exact invoice where available; a legacy untyped link does not certify invoice completeness. For cross-currency payments, match the invoice to Wise's original/exchanged amount, not a monthly FX estimate. Preserve the bank debit and its fees. A split-currency card payment has multiple Bank rows but one supplier invoice. - `economics_stripe_sales` stores reviewed Stripe account-month-currency sales, refunds, reversals, fees, stream, and coverage. It never stores customer or payment payloads. - `economics_pollen_usage` stores internal Paid and Quest consumption. Reconcile it at provider-month grain. Pollen model ids are accounting identities as recorded: today's registry aliases never merge them. A provider label joins a Pollen model only when it equals that month's Pollen id or through the reviewed `modelLabels` table in `operations/economics/provider-registry.json`. Add a label with the Pollen id it billed at the time, or `null` when it has no Pollen model. Group several ids in one entry only when they are the same model at the same provider billed on one line (a persona, resolution, or quality tier of one upstream); never group different models. Qualify the key as `label | sku` or `label | line item` when one label bills several ids on separate lines, and use dated rules (`{ "until": "2026-05", "model": ... }`) when a label meant a different id in a different period. Ids no longer in the shared registry stay valid through `retiredModels`. A Pollen row whose provider tag names a vendor that never billed it is re-attributed only through a bounded, evidenced `pollenVendorOverrides` entry (gptimage tagged azure-2 while billed on our Azure subscription, Jan–Apr 2026). Unjoined cost stays visible as needs mapping, shared upstream, or missing breakdown. Never spread it across models. - D1 `user` is authoritative for creator GitHub usernames and current balances. Paid and Quest Pollen are non-cashable usage exposure; Paid serves the full catalog, Quest only the eligible catalog. Never classify either as Revenue Share or subtract face value from cash runway. A staging snapshot includes positive-balance users plus all Revenue Share recipients. Keep only user ID, GitHub username, both balances, and sync time; required name/email fields stay empty. - `creator_payout` is a one-time Revenue Share settlement and operating expense. - Reuse the original deterministic `entry_id` when correcting a fact. Never create a second identity for the same fact. - Treat the current month as partial. Keep ledger writes task-scoped; do not add permanent ingest code. Before a write, query the effective datasource, save and verify a complete local backup, and show the exact proposed rows and totals. Existing `entry_id` corrections must include the current base version, use a later `recorded_at`, and preserve immutable identity fields. Append only after explicit approval for the named batch and environment, then re-query every written ID and save a verified after-snapshot. Validate staging first; production requires separate approval. Staging verification uses `operations/economics/secrets/web.dev.json:TINYBIRD_ECONOMICS_READ_TOKEN`. Never use deprecated `TINYBIRD_OPS_READ_TOKEN` to verify the Economics staging app; it can resolve to another workspace. Use the scoped ingest token only for raw datasource backup/read and the approved append. ## Completion A provider-month is complete only when account coverage, provider usage, and required invoice/statement evidence are all accounted for. Report missing sources directly; do not hide them with estimates or fallbacks.