Targets spreadsheet, ERP sales and trading calendar
Validated target matched with the ERP, official actuals and trading days per store
Achievement, remaining, required pace and projection by store and month
Daily store card, traffic light and AI agent
What it solves
- Each store sees how much is left and how much it needs to sell per open store day to hit the target.
- Achievement uses the same sales as the month-end close, without in-progress orders or quotes.
- The month-end projection has a declared method and lands on actuals on the last day.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- The targets spreadsheet connected to Nekt, with period, scope and value
- ERP, POS or marketplace sales connected
- Each store's trading day calendar (Sundays, holidays, extended hours)
What you get
- A long targets table, validated and with history by period
- Achievement, remaining, required pace and projection by store, channel and product, every day
- Daily store card and dashboard with a risk traffic light
- An AI agent that answers about targets with the same actuals as the close
Where to activate
Every morning: yesterday's sales, % of target, remaining and how much to sell per day, on WhatsApp or in the team chat.
Green on target with an adequate projection, yellow at risk and red with a projection below target, by store, channel and product.
Answers about targets with official actuals, each store's calendar and the declared projection method.
The math is simple. The care is in validating the spreadsheet on load, matching names with the ERP and building each store's trading day calendar. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
The targets spreadsheet has one tab per month, store and product names typed by hand and sometimes targets in units instead of reais. Actuals come from the ERP with another spelling and with gross sales, net sales, in-progress orders or quotes, depending on who built the dashboard. The most common projection divides sales by calendar days and ignores that the street store closes on Sunday, the mall store opens on holidays and the end of the month has a promotion. The result is an achievement that changes from dashboard to dashboard and an alert that arrives late.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
Load the spreadsheet into a table with period (first day of the month), scope (chain, store, channel, salesperson or product), scope key, unit (reais or units) and value. The load replaces only the rows present in the spreadsheet for that period and keeps the others and the other months. Declare what an empty cell means: some write zero, but no target does not enter achievement.
The load stops entirely, writing nothing, when it finds an invalid period, a target that is not a number, a negative target, a target in units with decimals, or two different targets for the same period and key after normalization. The error message lists the rows, so the spreadsheet owner can fix them.
Normalize names (uppercase, no accents, single spaces) and run them through an alias table to the ERP's canonical key: the same brand spelled two ways, the model with and without accents, the store by its neighborhood nickname. When an alias and the canonical name appear together in the same month, the canonical one wins. A row that matches no store or product in the ERP stops the load and goes to the pending list.
The actuals that go into achievement are invoiced net sales: invoice issued or order completed, without canceled orders, with returns deducted, in the same unit as the target. A paid order still in progress, a quote and a deal won in the CRM without an invoice appear in a separate column, as in progress, and never add to achievement. On marketplaces, validate which status means completed in each channel.
The chain target, the store targets and the channel or product targets live in the table together. Always sum filtering one scope. The sum of stores must match the chain target, or the difference shows up in an explicit row (e-commerce, marketplace, corporate sales). Head office and distribution centers with no consumer sales have no store target.
Pace and projection count trading days, not calendar days. Each store has its own calendar: a mall store opens on Sundays and holidays, a street store does not; promotion days with extended hours weigh more. Keep the calendar in a table by store and day, with open or closed and a weight, maintained by operations.
Use the closed day: actuals up to yesterday (trading date, America/Sao_Paulo). Remaining = the greater of target minus actuals and zero; any surplus goes to another column. Required pace = remaining / trading days left starting today. Achieved pace = actuals / trading days elapsed. Show both side by side and the ratio between them: 1.4 means the store needs to sell 40% above what it has been selling.
The simplest projection is actuals / trading days elapsed x trading days in the month. When the calendar has weights, use the weight of the remaining days instead of the count, and, if there is history, weight each weekday by average sales on the same weekdays of previous weeks. State on the dashboard which method is in use. Once the month is over, the projection equals actuals.
Compute bands on the base target (for example, 80%, 100% and 120%) for bonuses and the traffic light, always with official revenue. When the chain has a contribution margin target, show realized margin next to it and the deviation in percentage points: a store that hits sales by discounting may be far from the margin target.
The numbers for target tracking
Computed by scope and period, with actuals up to yesterday.
Definitions
Pitfalls that already happened
The spreadsheet listed the store by its neighborhood nickname and a brand spelled two ways. The rows did not match the ERP, the store showed zero achievement and the brand got two targets in the same month.
Alias dictionary to the canonical key and a load that stops when a name does not match.
A marketplace dashboard added paid orders still in transit to actuals, and the target looked hit before the orders were completed or canceled.
Achievement only with completed orders; paid in-progress orders in a separate column.
In the last week, a chain found out it needed to sell about 40% above the month's average pace to close the target, with the gap concentrated in two stores, and put together a month-end promotion in a rush.
Show the required effort (required pace / achieved pace) by store every day and alert when it passes an agreed limit.
In the same month, a chain's store achievement ranged from over 110% to under 60%, month after month in the same stores. The problem was the target distribution, not performance.
Compare each store's target with its sales history and show each store's share of the target and of sales.
A store ran 30% to 40% below target and was treated as a problem, even though it billed two to three times its break-even point.
Show the store's break-even point next to the target so the conversation is not only about achievement.
Acceptance test
The case is done when every item passes.
- For a closed month, the sum of store targets equals the chain target, or the difference appears in an explicit row.
- Each store's actuals for a closed month equal net sales in the ERP sales report for the same store and month.
- On the day after the month's last trading day, the projection equals actuals and no trading day is left in the required pace denominator.
- Remaining is never negative and % achieved for any slice is the ratio of that slice's sums.
- A spreadsheet with a negative target, an invalid period or a name with no match in the ERP writes no rows and returns the list of what to fix.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Store targets with projections (retail) - Targets in the long table: period, scope (chain, store, channel, salesperson, product), canonical key, unit (reais or units) and value. Always sum filtering one scope. - Actuals = invoiced net sales (invoice issued or order completed, without canceled orders, returns deducted) up to yesterday, in the target's unit. Paid in-progress orders and quotes do not enter achievement. - % achieved = actuals / target. Remaining = max(target - actuals, 0). - Trading days from each store's calendar (Sundays, holidays and extended hours vary by store). - Required pace = remaining / trading days left. Achieved pace = actuals / trading days elapsed. Show both and the ratio between them. - Projection = actuals / trading days elapsed x trading days in the month, unless a method is declared in <method>. Always state the method used. - Bands: 80%, 100% and 120% of the base target. - When there is a margin target, show the deviation in percentage points. - Do not compare achievement across stores without saying whether the target was calibrated on the store's history. Client exceptions: - <client>: product target in units by brand and model; actuals in units sold. - <client>: store <store> opens on Sundays and holidays; days <dates> with extended hours have weight <weight>. - <client>: chain target includes <channel>, with no per-store target.
Build the "Store targets with projections" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/varejo/metas-por-loja-projecao.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
Target by brand and model in whole units, compared with units sold in the ERP through the same canonical key.
One target per channel and account, with each marketplace's official revenue and the status that counts as completed in each one.
Achievement bands tied to the bonus policy in force by owner and period, only with registered rules.