Connect an assistant

Every Meta ad that spent in the period with its spend in your currency, Meta's purchases and value on their attribution window, cost per Meta purchase, hook and hold or link CTR, its launch date, its verdict against its own past, whether it is readable yet, and the three equal periods before it; with the account median, the campaigns and the market strip beside them.

An ad's spend is its share of what the P&L booked for its campaign and day, so the ads add up to the statement. There is no profit per ad: no order names its ad, and the answer says so rather than allocating one.

Results per Meta ad for a period, read beside the P&L and never booked: per ad its spend in the reporting currency (its share of what the P&L booked for its campaign-day, so the ads of a campaign sum to the statement), Meta's purchase count and value on the ad set's attribution window, cost per Meta purchase, hook and hold rate for a video or link CTR for a static, launch date and days live, the verdict (fatiguing, limited, holding, not readable yet, never delivered) with the multiple over the ad's own past and the past it was read against, whether it is readable and the spend still needed, and the three equal periods before; plus the counts behind the page's sentence, the account median with its n, the campaigns with their booked spend, and the market strip (contribution before and after ads per market, with the per-order figure). Every figure says whether Meta reported it or Vecks derived it. It refuses a profit, margin or return per ad, because no order names its ad and a per-ad margin would be an allocation nobody decided; the answer carries the refusals and their reasons, so say them rather than computing one.

The orders, campaigns or monthly amounts of a cost that a market, product or cost center does not reach in a month, each with what it booked and why, biggest first.

The same rows the cost model's allocation footer counts as a shortfall, so the two never disagree.

The rows of a cost that a dimension does not reach in a month: the orders (with ids), campaigns or monthly amounts behind the cost model's "X of Y allocated to products / markets / cost centers" shortfall, each with what it booked and why the money cannot reach a product, market or cost center (a charge per order not split by product, an order with no product to split by, a campaign with no market, a monthly amount). Use it to name the exact orders behind a gap instead of guessing.

The same statement split by one dimension: market, product, sales channel, campaign, cost center, or customer (new, returning, or unknown where the channel supplies no customer, as Amazon never does), with every stage per value.

Costs that carry no value for the dimension you chose are reported as unallocated rather than spread, so a market figure is never flattered by a cost that was never attributed to it.

P&L broken down by one dimension (market, sku, channel, campaign, cost_center, customer_type) for a date range. Amounts per dimension value and stage. customer_type is new, returning or unknown, from the order's rank in its customer's history; Amazon orders are always unknown.

The per-unit cost of every product in every market, broken into its components, and the per-order rules beside it.

The cost coverage matrix: per-unit cost per SKU and market with per-component breakdown, plus the per-order rules. Shows exactly which SKU/market combinations have missing or partial cost rules.

Stock per product: on hand as the last count plus what arrived minus what sold since, units sold per day over the last 30 days, days left with the run-out date, and the shipments on their way.

On hand is derived from a count and the ledger, never kept as a running figure. A product nobody has counted reads as not counted rather than zero; a refund covering a whole order is read as the goods coming back.

Stock per product: on hand (last count + received - sold + returned since it; null = never counted), the last count (with its id), units sold and returned in the pace window, the selling pace in units per day, days left and the run-out date, open shipments (incoming units, next expected date, ids). Counts and shipments are recorded through propose_change (stock_count, inbound_create, inbound_receive, inbound_delete); none of them touches the ledger.

The structure you have arranged: your subtotals in order, the sections under each, and the lines in each section, with the ids a change refers to.

Every one of these is yours to rename, move or remove. The statement is not a fixed shape we impose.

The statement's structure as the merchant has arranged it: subtotals in order (with ids), the sections under each (ids, labels), and the cost lines in each (item keys, labels). Everything here is the merchant's own and can be renamed, moved, reordered, added or deleted through propose_change (section_update, subtotal_update, cost_move, section_assign, item_create ...). Read it before saying something cannot be changed.

One order as the ledger booked it: every revenue and cost row, the rule that produced each, quantities, the exchange rate, and anything flagged. An order number is only unique within its channel, so give the channel when you know it.

Opening an order is written to the access log, exactly as it is when you open one in Vecks.

One order exactly as booked in the ledger: every revenue and cost row with the matched rate (scope, note), quantities, FX, and any data-quality flags. Use to answer 'why does this order cost X'. An order number is only unique within its channel, so give the channel whenever it is known.

Every line of your statement for the dates you give, in your reporting currency, with the order count. The same figures the dashboard shows, from the same ledger.

Refund timing is a choice: 'actions' puts a refund on the day the order was placed, 'reconciliation' on the day the money went back.

P&L summary for a date range: every line (revenue, costs, profit stages) in EUR, plus the order count. timing 'actions' books refunds on the order date, 'reconciliation' on the refund date.

Your start date and reporting currency, the market map, and the rules that decide what each ad campaign counts for.

Tenant settings and mappings: start date, reporting currency, the market map (which ship countries are broken out as their own market; everything absent books as 'Others'), and the campaign rules (conditions on a campaign's platform, name, delivery country or tag → the markets it counts for, with a spread, a product and a cost center).

How completely the month's orders carry their costs, per category, plus the gaps that are blocking and the data-quality issues by kind.

Four states: loaded, awaiting actuals, a rule exists but nothing matched, and no cost logic at all. The last two are why a profit figure can be too high.

How completely costs are attributed for a period (YYYY-MM or YYYY): per-category states (green = loaded, amber = estimates awaiting actuals, red = a rule exists but something didn't match, grey = no cost logic at all), the blocking gaps, and data-quality issue counts by kind.

Every monthly amount with its P&L line, value, currency and the months it runs.

A monthly amount is spread daily, so a month is never a step at the end of it.

Every fixed (monthly) cost line with id, P&L line, label, monthly amount, currency and validity. Fixed costs spread daily: monthly amount divided by days in the month.

Registered products and bundles with what a bundle is made of, and any product seen in an order that nobody has registered.

The product (SKU) registry: single SKUs and bundles with their composition, plus any unknown SKUs seen in orders that are not registered.

Every cost rule with its scope, basis, amount, currency and dates, split into what is in force and what it replaced.

Rules are versioned rather than overwritten, so the history is here too, and the ids are what a change refers to.

Every cost rate, grouped by P&L line and component, split into active and history versions. Includes each rate's id (needed for rate_update/rate_end/rate_delete), scope (sku/country/market/channel, null = all), basis, amount, currency and validity. For pct_of_net rates the amount is a percentage.

The cost stack that would resolve for a product, country, market and channel you name, component by component.

It answers from the rules without touching an order, so it is the way to check a rule before anything is booked against it.

Resolve the live cost stack for a hypothetical order line: which rate wins for every component given a SKU, ship country, market and channel. The same resolution the ledger uses (most specific rate wins).

The change committed, and the ledger rebuilt so every figure moves with it.

It takes a proposal id and nothing else, so there is always a preview behind a commit; a proposal can be used once and expires after fifteen minutes.

Commit a change that propose_change already previewed, by its proposal_id. Call this only after you have shown the person the impact and they have agreed to it. A proposal can be applied once and expires fifteen minutes after it was made; there is no way to apply a change that was not previewed first.

The change run against your real orders inside a transaction that is rolled back, and the whole P&L before and after it. Nothing is written.

This is the only way a change is ever prepared, and it can never commit. What it hands back is a proposal id.

Propose one config change to the user. This DOES NOT apply anything: the change is test-run in a rolled-back transaction and you get back its P&L impact; the user sees a card with the impact and an Apply button, and only their click commits it. Use real ids from list_rates / list_fixed_costs / get_layout / get_settings. Everything the admin UI can change is here, including the statement's own structure (sections, subtotals, the order of lines).