---
id: varejo/metas-por-loja-projecao
industry: Retail and e-commerce
usage: common
effort: low
grain: Period x scope (chain, store, channel, salesperson or product); day for daily tracking
---

# Store targets with projections

How much of the month's target each store, channel and product has already done, how much is left, how much it needs to sell per open store day and where it should close, with the spreadsheet target and the ERP actuals speaking the same language.

## Executive summary

**For:** Sales leadership and store managers who track the month's target and need to know, every day, whether it will be met.

**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.

**Why it matters:** The target lives in a spreadsheet with store and product names that do not match the ERP, and each dashboard's actuals use a different definition of sales. The manager only finds out the target will be missed in the last week, when the required pace is already well above what the store usually sells. With the right number every day, the chain decides early where to focus action, and leadership sees whether the target was well distributed across locations.

**Business questions it answers**

- How much of the month's target has each store done and how much is left?
- How much does each store need to sell per day until month end to hit the target?
- Which store or marketplace is at risk of missing the target?
- Where will the month close if the pace stays the same?
- Are we hitting the sales target with the agreed margin?
- Is the target well distributed across stores, or are some always far above and others far below?

**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

## Detailed

### The problem

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.

### Business rules

1. **The target is a long table with a declared unit.** 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. (Avoid: Keeping the wide spreadsheet, with one column per month and no indication of reais or units.)
2. **The load validates before writing.** 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. (Avoid: Writing whatever could be read and silently dropping rows with errors.)
3. **Spreadsheet names go through a dictionary.** 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. (Avoid: Matching target to sales by the text typed in the spreadsheet.)
4. **Actuals are the scope's official revenue.** 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. (Avoid: Adding paid in-progress orders or quotes to target actuals.)
5. **Scopes do not add up to each other.** 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. (Avoid: Adding the chain row and the store rows in the same total.)
6. **Trading days come from each store's calendar.** 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. (Avoid: Dividing the remaining by the calendar days left until month end.)
7. **Required pace up to yesterday.** 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. (Avoid: Mixing today's partial sales with closed days in the pace.)
8. **Projection with the method written on the dashboard.** 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. (Avoid: Projecting by calendar-day pace without saying how it was computed.)
9. **Bands and margin target alongside.** 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. (Avoid: Celebrating the sales target without looking at the same month's margin.)

### The numbers for target tracking

Computed by scope and period, with actuals up to yesterday.

- **Target** → Value from the validated spreadsheet, in reais or units
- **Actuals** → Official revenue up to yesterday (`invoiced net sales`)
- **% achieved** → Actuals / target (`actuals / target x 100`)
- **Remaining** → Never negative (`max(target - actuals, 0)`)
- **Achieved pace** → Per elapsed trading day (`actuals / trading days elapsed`)
- **Required pace** → Per remaining trading day (`remaining / trading days left`)
- **Required effort** → How far above the current pace (`required pace / achieved pace`)
- **Projection** → Close at current pace, declared method
- **Bands** → 80%, 100% and 120% of the base target

### Definitions

| Metric | Definition |
|---|---|
| Target | value from the targets table for the period, scope and key, in the declared unit |
| Actuals | invoiced net sales of the scope, from the start of the period to yesterday, without canceled orders and with returns deducted |
| % achieved | actuals / target x 100, by scope and period, recomputed for each slice from the sums |
| Remaining | the greater of target minus actuals and zero |
| Trading days | days marked as open in the store's calendar; elapsed up to yesterday, remaining from today to month end |
| Required pace | remaining / trading days left (or / sum of remaining weights) |
| Month-end projection | actuals / trading days elapsed x trading days in the month, or by the sum of weights when the calendar has weights |
| Margin deviation | realized contribution margin % minus target margin %, in percentage points |

### Pitfalls

- **A store at 0% that was selling.** 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. How to avoid: Alias dictionary to the canonical key and a load that stops when a name does not match.
- **Achievement with orders that did not close.** A marketplace dashboard added paid orders still in transit to actuals, and the target looked hit before the orders were completed or canceled. How to avoid: Achievement only with completed orders; paid in-progress orders in a separate column.
- **Required pace noticed too late.** 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. How to avoid: Show the required effort (required pace / achieved pace) by store every day and alert when it passes an agreed limit.
- **A target that does not fit the location.** 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. How to avoid: Compare each store's target with its sales history and show each store's share of the target and of sales.
- **Below target, but profitable.** 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. How to avoid: Show the store's break-even point next to the target so the conversation is not only about achievement.

### Acceptance test

- [ ] 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.

### Context document

```text
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.
```

### Variations

- **Target in units by product:** Target by brand and model in whole units, compared with units sold in the ERP through the same canonical key.
- **Target by marketplace:** One target per channel and account, with each marketplace's official revenue and the status that counts as completed in each one.
- **Bonus by band:** Achievement bands tied to the bonus policy in force by owner and period, only with registered rules.