Kroger 84.51 OnDemand: reports and columns

A Kroger supplier hears four names for what feels like it ought to be one thing: 84.51, Market6, Stratum and OnDemand. They are not one thing, they are not interchangeable, and the single most common way to waste an afternoon here is to go looking in the wrong one.

This guide covers OnDemand, the portal at ondemand.kroger.m6demandview.com that you reach with a plain username and password. It is where the flat, exportable, column-level data lives. Sixty-five reports sit in its library; five of them carry the bulk of what a brand analyst needs, and this guide takes each one apart to the column.

One thing to establish before anything else, because it changes what every number here means. Kroger is a retailer, not a distributor. The reports below are built on what actually scanned at the register, not on what was shipped into a warehouse. Everything the distributor portals cannot tell you about consumer demand, this portal can. What it is worse at is the supply chain into the store, and that asymmetry runs through the whole library.

What that asymmetry means in practice, before any of the detail. OnDemand is excellent at four questions and poor at two.

It will tell you, at store granularity and by fiscal week, what sold and for how much, who else sold it in the same category, where you are authorized to be on shelf, and how much of your volume came through Pickup and Delivery rather than through the aisle. The competitor part is unusual enough to be worth saying twice: with one checkbox left alone, a Kroger export hands you category-wide scanned dollars and units, competitor by competitor, at individual store level.

It is poor at two things. It cannot tell you why anything happened, because that is Stratum's territory and it is sold separately. And it cannot join its own supply chain to its own sales without work from you, because the inventory report keys on a case code and everything else keys on a UPC.

84.51 publishes no data dictionary for any of it. The parameter panels carry no field definitions, and the export headers are database column names. Everything below was recorded from the portal and from the exports themselves, which is also why the column tables are generated rather than typed: they come from the same catalog the files are loaded into, so they cannot drift away from what actually arrives.

How the Kroger 84.51 OnDemand portal works

Four names, two products, and a report library big enough that finding the right report is most of the work.

The 84.51 portal stack

84.51 is Kroger's data science subsidiary, and it is the company behind every name in this section. It sells two separate analytics products to suppliers, and you can be entitled to one, the other, or both.

Stratum, at stratum.8451.com, is the newer one. It signs in through Okta with multi-factor authentication.

OnDemand, at ondemand.kroger.m6demandview.com, is the older one. It signs in with an ordinary username and password.

Market6 is the company 84.51 merged with in 2016. OnDemand is what came out of that: its reporting engine was called DemandView, which is why the host name still says m6demandview a decade later. When somebody on a Kroger call says "pull it from Market6", they mean this portal.

So the practical test is the address bar. 8451.com means Stratum. m6demandview.com means OnDemand. If somebody sent you a screenshot and you cannot tell which product it came from, the URL settles it in a second and the feature list will not, because the two overlap heavily.

Note that OnDemand itself carries a Go to Stratum link in its top navigation, so moving between them is one click and it is genuinely easy to lose track of which one you are in.

Two naming notes, because both send people to the wrong place. The company writes itself as 84.51°, with a degree sign, after the latitude of Cincinnati; it is the same company as the "8451" in the Stratum URL and the "84.51" everyone types. And Kroger Precision Marketing is a third 84.51 product entirely, the retail-media arm that sells advertising. None of the reports below live there.

OnDemand vs Stratum

They are not versions of each other. Stratum is a loyalty-and-insights product built on Kroger's shopper data; OnDemand is a reporting product built on scan, inventory and assortment data. Different questions, different sign-ins, different entitlements, sold separately.

The distinction that matters day to day is what you can get out. OnDemand exports flat CSV at whatever grain the report is defined at, which is what makes it the portal a data pipeline can be pointed at. That is why this guide exists and why the columns below are worth knowing by name.

On whether OnDemand is going away: 84.51 has published no timetable for retiring it, and it is worth being precise about that, because a widely repeated version of this is wrong. The portal does carry a deprecation notice, and it is specific:

Supply Chain On-Time Report Deprecation: This report will be deprecated on 08/29/2026 and replaced with On-Time Period/Weekly PO Status reports.

That is one report inside OnDemand being replaced by two others inside OnDemand. It is not a statement about the portal, or about CSV export, or about a migration to Stratum. Both On-Time Weekly PO Status and On-Time Period PO Status are already in the library alongside the report they replace. If you are planning around a Kroger data source, plan around that notice and not around a rumour built on top of it.

For which Kroger data source to buy in the first place, rather than what is inside the one you already have, see SPINS vs 84.51 Stratum vs Circana for Kroger data.

The report library

OnDemand ships 65 distinct reports, and no public list of them exists. Here is the shape of the library, grouped the way the reports actually cluster.

Two things to take from that table rather than from the list itself.

The library is entitlement-scoped. What you see is what your account is provisioned for, so another supplier's OnDemand can hold a different set. Treat the table as a map of the territory, not as an inventory of your own portal.

Most reports exist at more than one level, and that is the subject of the next section. Sherlock Store Matrix appears at all four levels. So does Store Authorization Detail. The name alone does not tell you what the export will contain.

The five reports this guide covers in depth are Sherlock Store Matrix, Store Authorization Detail, Digital Performance Integrated, Warehouse Inventory and Out-of-Stock Weekly by Division. They were chosen because between them they answer sales, assortment, digital mix, supply and availability, which is most of a brand analyst's week.

Here is where to start for everything else, which is the routing nobody hands you:

Two families in that table are worth knowing about even though this guide does not take them apart. The Ordered vs. Shipped and Shipped vs. Scanned pair is the fill-rate story: the first says whether Kroger got what it asked its own supply chain for, the second says whether what reached the store left it. Between them they close the loop that Sherlock and Warehouse Inventory each see only one end of. And the Planogram family is the only place in the portal that describes the physical shelf, which is where a distribution argument usually ends up.

Reading a parameter panel

Every OnDemand report opens on a parameter panel rather than on data. You choose a report level, fill in the tabs, then click Run Report. Three behaviours are worth knowing before you fight with one.

The tabs differ per report, and they are the report's real signature. The five reports in this guide have five different tab sets:

Read that table as a description of what each report is. Store Authorization Detail has no Dates tab because it has no time axis. Warehouse Inventory has no Divisions or Stores because its geography is distribution centres. Digital Performance has a GTINs tab instead of Products because it works from a UPC list rather than a category. If a tab you expect is missing, the report is not cut that way, and no amount of filtering will make it so.

Panels are dependent, and an empty list usually means an unmade choice upstream. The commodity list is populated by the department choice above it; the DC list on Warehouse Inventory renders only after products are selected. A report that looks broken on first load is normally a report waiting for you.

The lists are scoped to you. Once the cascade runs, a dropdown shows only the values you have data for. That is convenient and it means you cannot use the panel to learn Kroger's full vocabulary for anything.

The Dates tab is worth a closer look because it carries more than a range. It offers Ad Weeks or Fiscal Weeks as a radio choice, a Start and an End drawn from a dropdown of named fiscal weeks rather than a calendar, an Include Future Dates checkbox, and a running Number of Weeks Selected counter. Digital Performance Integrated adds a second Start and End for the Previous range, plus a "Mirror" Current and Previous Dates checkbox that keeps the two in step. That second range is where the paired _CUR and _PRE columns in the export come from.

One more distinction that explains a column that is often absent. The Locations tab splits its store attributes into Filter Attributes and Display Attributes. Filter attributes are the dimensions the report can break by: Division, Store Number, Store City, Store County, Store State, Store Banner, Store Type, Store Status, Store Zone, Store Sells Pickup. Display attributes are descriptive extras: Store Name, Store Address, Store Zip, Store Phone, Store Open Date, Store Close Date, Pickup Open Date. They are ticked separately, and whichever set you left alone simply will not be in the file.

That is why two suppliers on the same report can hold exports of very different widths and neither is broken, and the gap is not marginal. Sherlock Store Matrix runs 18 columns narrow against 33 wide, and almost all of that difference is the store-attribute block. Digital Performance runs 25 against 75, where the store attributes are only part of it and the modality grid is the rest. So a file that looks short next to a colleague's is usually a panel setting rather than an entitlement difference, and the header count tells you which before you conclude you are missing data.

How Kroger names things

Kroger's vocabulary is where most of the misreading happens, because several of these words mean something more specific here than they do in the trade generally.

Report levels

Before you open a report you choose its level, from a dropdown that offers four options: Division Commodity, Division GTIN Group, Store Commodity and Store GTIN Group. It is a grid of two choices, and the portal never says so.

The first word is the geography grain. Division means one of Kroger's operating divisions; Store means one physical store. The second is the product grain. Commodity means a whole Kroger category, competitors included. GTIN Group means a specific list of UPCs that you paste in.

The consequence is the part people get caught by. The same report name exists at several levels, and the export columns differ between them. Store Authorization Detail is in all four; so is Sherlock Store Matrix. Opening the right report at the wrong level gives you a file that looks plausible, carries the columns of a different cut, and has no marker in it saying which level produced it.

A worked example of how far apart two levels are, on invented numbers. Sunrise Cookies runs one commodity across one division for one fiscal week. At Division Commodity the export is one row per item per division: 40 items, one division, 40 rows. At Store Commodity it is one row per item per store: the same 40 items across 190 stores in that division, so 7,600 rows, and the dollar total across them is identical. Both files are correct and only one of them can answer "which stores stopped selling it".

Run the same pull at Division GTIN Group with a nine-UPC list and you get 9 rows, not 40, because the GTIN list replaces the category rather than filtering it. The competitor items are not filtered out, they were never requested.

So when you save the file, put the level in the filename. When somebody hands you a Kroger export and asks why it will not join to yours, the level is the first thing to check and there is no way to recover it from the data.

The product hierarchy

Products are chosen through five nested levels, each populated by the one above it: Primary Department, then Recap Department, then Department, then Commodity, then Subcommodity.

The levels carry numeric prefixes that stay attached in the export, so a commodity arrives as 085 COLD CEREAL and a subcommodity as 08502 MAINSTREAM GRANOLA. That is a three-digit code for commodity and a five-digit code for subcommodity, and the first three digits of the subcommodity are usually, but not always, the commodity.

Two department facts that cost people time:

A brand's category can span two departments. A natural-foods item and its conventional twin can sit in 01 GROC-ALL OTHER and 17 NATURAL FOODS respectively, and if you tick only one you silently lose half the category. The subcommodity codes give this away: the natural-foods side of a category carries its own numbering, so seeing 98324 CEREAL - COLD alongside 08501 COLD CEREAL SINGLE SERVE in the same export is normal, not duplication.

The panels are dependent, so order matters. Choosing at Primary Department repopulates everything below it, and changing it late discards the choices you made after it.

There is a sixth step on some reports, Attributes, which is not a filter at all: it chooses which descriptor columns come out in the export. Leave it unset and the file arrives without the commodity, subcommodity and manufacturer columns you were expecting, which reads as missing data rather than as an unmade choice.

A worked cascade, on invented numbers. Sunrise Cookies ticks 01 GROCERY at Primary Department. Recap Department then offers two entries, 01 GROCERY and 17 NATURAL FOODS, because the brand's items scan in both. Ticking only the first carries 5 of the brand's commodities and drops 2, so the category total comes back around 71% of the real figure with nothing on screen saying so. Ticking both carries all 7. The panel gives you no warning either way, which is why the department step is the one to slow down on.

What a commodity is

A commodity is Kroger's category. It is a merchandising unit that Kroger defines and maintains, not a syndicated category definition, and it is the unit almost every OnDemand report is scoped by.

That distinction matters more than it sounds. A SPINS or Circana category is a research-house construct, drawn to be comparable across retailers. A Kroger commodity is drawn to run a Kroger aisle. The two do not line up, and a share number computed in one and compared to a share number computed in the other is not a comparison of anything.

Some worked shape, on invented numbers. Suppose Sunrise Cookies sits in commodity 238 LIFESTYLE BARS, and its OnDemand pull shows 4,000 scanned units against a commodity total of 100,000, so 4.0% commodity share. The syndicated category the brand reports to the board is a "wellness bars" definition that excludes two of the subcommodities Kroger folds into 238 and adds one Kroger files elsewhere. On the same weeks, the same brand shows 4,000 units against 80,000, or 5.0% share. Neither number is wrong. They answer different questions, and the 1-point gap is definitional, not performance.

The practical rule: use commodity share to talk to a Kroger buyer, because it is the number on their screen, and use your syndicated definition to talk to your own board. Say which one you are quoting, every time.

Finding your own commodities is easier than it sounds and nobody tells you how: pull any report at Commodity level with Only my products ticked, and the COMMODITY and SUBCOMMODITY columns that come back are exactly the ones your items scan under. Untick it and re-run the same scope, and you have the category those commodities define. That two-pull sequence is the reliable way to scope a Kroger category, because the commodity list in the panel is scoped to your entitlement rather than to your items, and the two are not the same set.

One more thing the codes tell you. Commodities are numbered by department, so the 6xx range is natural foods and the low numbers are conventional grocery. A brand appearing in both 085 COLD CEREAL and 633 NF CEREALS is not double-counted; it is one brand whose items are merchandised in two different aisles, and a Kroger buyer will treat those as two conversations.

Divisions, banners and stores

Kroger's geography has three levels in these exports: division, banner and store. They do not map one to one, there are more banners than divisions, and the division arrives in a column called RPT_SHORT_DESC, which is the one name here that tells you nothing about what it holds.

Division is the operating unit, and it arrives in the column named RPT_SHORT_DESC. That name is misleading enough to be worth stating plainly: despite reading like metadata about the report, RPT_SHORT_DESC holds values like 21 Central, 703 Ralphs and 620 King Soopers. The count differs by report: the sales and digital exports carry 24 distinct values and the assortment and out-of-stock ones carry 23, because only the first pair include 540 Kroger Fulfillment Network. It is a grain key on most of these reports, and the Locations panel that emits it labels the attribute plainly as Division. The confusing name appears only in the file.

Banner is the name over the door, and it arrives in STO_BANNER. There are more banners than divisions, and they do not map one-to-one: a single division can carry a plain banner and several of its store formats, which is why counting banners and counting divisions give very different answers.

Store is the individual shop, in RE_STO_NUM or RE_STORE_NUM.

Three traps live in that arrangement.

Store numbers are not unique on their own. The same store number exists in several divisions. Join on division plus store or you will merge unrelated shops, and the result will look fine because both are real stores. Live exports carry about 1,044 distinct store numbers, all of them between 1 and 999, spread across roughly 2,500 stores. That is two or three stores per number, so a join on store alone silently folds a Ralphs and a King Soopers into one row and adds their sales together.

Banner names are truncated to 20 characters in the export. King Soopers Marketp and Pick n Save Marketpl are not data-entry errors, they are the full name cut off. If you group by banner, one real banner can arrive under two spellings, and a naive count of banners overstates.

A division is not a banner and neither is a region. 540 Kroger Fulfillment Network is the one to know about: it is the e-commerce fulfilment operation rather than a set of shops. It behaves like a division in the sales and digital reports, is absent from the assortment and out-of-stock ones, and has no physical stores behind it, so a per-store average that includes it is not measuring what you think, and a division count that differs by one between two of your files is probably this and not a data problem.

Banner-level analysis, as opposed to what the columns are, is covered in Kroger banner vs. total in SPINS aggregates.

Consumer UPC vs Base UPC

OnDemand works in two UPC forms and asks which one you want, as a Base UPC / Consumer UPC radio. It is a small control that decides what a row means, and two reports set it differently by default, which is why their exports do not join on the column they both call UPC.

The radio sits on the Products tab of Out-of-Stock Weekly by Division and on the GTINs tab of Digital Performance Integrated. Sherlock Store Matrix does not offer the choice at all, which is its own kind of trap: you cannot set it, so you have to know what it did.

Consumer UPC is the code on the item the shopper buys, the one that scans at the register. Base UPC is the code that groups a set of consumer UPCs Kroger treats as one item, which is how a promotional multipack, a shipper and the plain version of the same product get pulled together.

The Digital Performance guidance selects Consumer UPC; Out-of-Stock selects Base UPC. That is not an inconsistency in the reports, it is a consequence of what each measures: a scan is a consumer UPC event, and an empty shelf is a base-item condition.

The join problem this creates is real. Pull sales at consumer UPC and availability at base UPC and the two files will not join on the UPC column, because they are different codes for different concepts. OnDemand ships a report for exactly this, Enterprise Base to Scan UPC Lookup, and it is the mapping you need before joining any two reports that made different choices here.

A worked example of what the mismatch costs, on invented numbers. Sunrise Beverage has 9 consumer UPCs, which collapse to 6 base items because three of them are club and multipack versions of items it also sells singly. Join the sales file to the availability file on the raw code and 6 of the 9 rows match, 3 fall out, and the 3 that fall out are exactly the promotional versions, which are the ones most likely to have gone out of stock. The join loses 33% of the rows and it loses them non-randomly, which is worse than losing a third at random.

One more UPC form to know about: CAS_SCN_CD_TX on Warehouse Inventory is a case scan code, a third thing again, and neither of the two above. So a brand can be holding three different identifiers for one product: the consumer UPC it sells, the base UPC Kroger groups it under, and the case code Kroger warehouses it by.

The Kroger fiscal calendar

Kroger runs a 13-period fiscal year of four weeks each, which is 52 weeks, occasionally 53. Weeks run Sunday to Saturday. The period number is the week number divided by four and rounded up, so week 17 is period 5, week 1.

Week names arrive in the export like this:

2026  PD 05  WK 1  (17)

That is fiscal year 2026, period 5, week 1 of that period, week 17 of the year. Alongside it, PERIOD_DESC spells the same period out as Fiscal 2026 Period 5.

Now the trap, which is the whole reason this section exists. The four-digit year is not the calendar year. Fiscal 2026 begins on Sunday 1 February 2026 and ends on Saturday 30 January 2027. So:

• Week 1 of fiscal 2026 is the week ending Saturday 7 February 2026.
• January 2026 belongs to fiscal 2025, not 2026.
• Week 17 of fiscal 2026 runs Sunday 24 May 2026 to Saturday 30 May 2026.
• A 53rd week, when there is one, extends fiscal 2026 to Saturday 6 February 2027.

Joining Kroger data to a calendar year on the four-digit label alone therefore misplaces roughly a month of it. Joining it to another retailer's fiscal calendar is worse, because everybody's year starts somewhere different.

A worked conversion, since the arithmetic is not obvious. Fiscal 2026 ends on the Saturday closest to 31 January 2027, which is Saturday 30 January 2027. Fifty-two weeks is 364 days, so week 1 starts 363 days before that end date, on Sunday 1 February 2026. Week 17 starts 16 weeks later, 112 days on, which is Sunday 24 May 2026, and ends the following Saturday, 30 May 2026. That matches the (17) in the week name above.

Because that arithmetic is the same every year and nobody publishes the result, here is the whole of fiscal 2026. Every date is a Sunday start and a Saturday end, and the same table shifts by one week each year.

Read down the Ends column and the point of the whole section becomes visible. Period 1 happens to finish on the last day of February this year and period 2 on 28 March, which looks reassuringly monthly, and then period 3 ends on 25 April and the illusion breaks. A Kroger period is not a month, it is four weeks, so it drifts against the calendar by two or three days a period and by roughly a month over a year. Quarters are the same story: a Kroger quarter is thirteen weeks and ends mid-month more often than not.

The practical consequence for reporting is that a Kroger period cannot be compared to a calendar month without deciding what you mean. Four-week periods against calendar months puts a different number of selling days in each, and Christmas in particular lands in period 11 or period 12 depending on the year. Compare period to period, or week to week, and convert only at the point where somebody outside the Kroger conversation needs a month.

Ad Weeks are a second calendar, offered on the same Dates tab as a radio choice against Fiscal Weeks. Ad weeks are the promotional calendar and they are numbered differently, in a YYYYPPWW form. The portal's own updates panel refers to data gaps by strings like ad week 20251204, which is fiscal 2025, period 12, week 4. Picking Ad Weeks when your pipeline expects Fiscal Weeks produces a file with plausible dates that lands in the wrong buckets, and nothing in the export names which mode produced it.

The reports

Five OnDemand reports and one upload, in the order a brand analyst usually needs them.

Sherlock Store Matrix

Scanned dollars and units for every item in a category, at every store, for one fiscal week. Opened at Store Commodity level. This is the register-level read and the closest thing in the portal to raw POS.

Sherlock Store Matrix is the workhorse. One row is one item at one store in one fiscal week, and it carries SCANNED_RETAIL_DOLLARS, SCANNED_MOVEMENT in units, GROSS_MARGIN_DOLLARS, and the full store attribute block: banner, address, county, price zone, format, open and close dates. Because the level is Commodity rather than GTIN Group, the export contains the whole category, your competitors included, at store granularity. There is no other supplier- facing Kroger source that gives you that.

A worked example on invented numbers. Sunrise Cookies pulls week 17 of fiscal 2026 across a two-commodity scope and gets 6,072.00 dollars on 1,100 units for one item across the division. That is an average retail of 6072 divided by 1100, or 5.52 per unit. If the shelf price is 5.99 and the item was not on promotion, the gap is the tell: a 0.47 spread means some of those units moved at a lower ring somewhere, and the store-level rows are where you find which ones.

Three traps.

Dollars and units both go negative. Returns and voids net into the same columns, so a store-week can show minus 812.40 dollars. Filter carefully: excluding negatives inflates the total, and treating them as sales understates it.

SCANNED_LBS is almost always zero. It carries random-weight pounds, which is meaningful in produce and meat and not in packaged grocery. Do not compute anything from it without checking that it is populated at all.

GROSS_MARGIN_DOLLARS is Kroger's margin, not yours. It is the retailer's gross margin on the scanned dollars, which is a genuinely useful number to know before a line review and a misleading one on a supplier P&L.

Grain is item by store by fiscal week. Refresh is weekly, and 84.51 publishes complete weeks, so the most recent complete fiscal week is the one to pull.

Sherlock is a family, not a report. The library carries Sherlock Enterprise, Sherlock Division and Sherlock Store, each in Matrix and Standard form, which is six reports with almost the same name. The first word is the geography the rows are cut at, so Enterprise is all of Kroger on one row per item, Division is one row per item per division, and Store is the store-level version this section describes. Matrix is the wide, item-by-geography layout; Standard is the plainer list. If you only ever need the national number, Sherlock Enterprise is a file a thousand times smaller than the one described here, and picking Store when Enterprise would do is the most common reason a Kroger pull takes twenty minutes.

There is also a Daily Store Matrix, which is this report at day grain. Use it when you are watching a launch or a promotion week by day; the weekly one is the right default for everything else, because the daily version multiplies the row count by seven for a signal that is mostly noise at item-store level.

Store Authorization Detail

Which items are authorized to be sold in which stores, right now. Opened at Store Commodity level, snapshot only, no date parameter at all. The assortment truth for a Kroger distribution conversation.

This is the report to reach for when the question is "where am I supposed to be on shelf", as distinct from "where did I sell", which is Sherlock. One row is one item at one store, with R_STORE_AUTH carrying the status.

The single most important property of this report is what it does not have: a date. It returns the current state and nothing else. Its own in-app export guide says so outright, that it does not include any historical data. Scout snaps it to a Saturday, which is the only way it gets a time axis, and that has a consequence covered in snapshot vs rolling-event: a week nobody pulled it is a week nobody can reconstruct.

Two traps.

R_STORE_AUTH has four live values and 84.51 documents none of them. A reads as authorized. O, U and X also appear in live exports. Confirm the meanings with your Kroger contact before building a rule on them, and do not assume that anything not A is unauthorized.

Authorized is not stocked. An authorization is permission to carry, and a store can be authorized and have never ordered the item. The distribution number a broker quotes is usually stores selling, which is a Sherlock question, and the two differ by a margin large enough to start an argument. If you need both, pull both and compare them item by item.

A worked example. Sunrise Cookies is authorized in 900 stores and, in the same week's Sherlock pull, rings at least one unit in 712 of them. That is 79.1% conversion of authorization into movement, and the 188-store gap is the actual work: some are new authorizations that have not shipped, some are voids. The number nobody can act on is "900 stores".

Note also that the store attribute block on this report is often only partly populated, so do not rely on STO_CITY or STO_TYPE being present on every row.

Two neighbours in the assortment family are worth knowing. Stores Selling answers the other half of the question this report raises: it counts stores with movement rather than stores with permission, so pairing the two is how you get the authorization-to-selling conversion above without doing the join yourself. Variety Optimization is Kroger's own view of which items in a commodity earn their space, which is the report a buyer is likely to be looking at in a line review. Neither is covered in depth here, and both are in the library at Division Commodity level.

Its Products tab is also built differently from the others: instead of the checkbox panels, it uses a dropdown cascade, one department at a time. For a brand whose category spans two departments that means running the report twice and concatenating, because there is no way to tick both at once.

Digital Performance Integrated

Scanned sales split by how the shopper bought: in store, Pickup, Delivery, fuel centre. Opened at Division GTIN Group level, so you supply a UPC list. Carries a built-in comparison period.

This is the e-commerce report, and it is the widest export in the set at 72 columns. Two things make it structurally different from Sherlock.

It is a GTIN Group report, so you paste in a list of UPCs rather than selecting a category. That makes it precise and it makes it your job to keep the list current; a new item that is not on the list is simply absent, with nothing to tell you it is missing.

The GTINs tab offers four scope modes for that list: GTIN List Only, Add Linked Siblings, Add Linked Siblings and Parents, and Add Markdown GTINs. The first is exactly what you pasted. The middle two expand it to related items Kroger links to yours, which is useful for catching a multipack you forgot and dangerous if you are computing a per-item number, because the row count no longer matches your list. Markdown GTINs are clearance codes, and including them moves the average price down.

Every measure comes twice, as _CUR and _PRE. Those are the Current and Previous date ranges from the Dates tab, so the report carries its own comparison period rather than making you pull twice and align them. It is a genuine convenience and it is also why the column count is what it is.

The modality split is the reason to use this report at all, and it has enough detail to need its own section.

A worked example. Sunrise Beverage pulls one fiscal week and sees 12,400 total scanned retail dollars, of which 3,100 came through Pickup and Delivery combined. That is a 25.0% digital share. The prior-period columns on the same rows show 11,800 total and 2,360 digital, or 20.0%. Total sales grew 5.1% while digital sales grew 31.4%, which is a mix story rather than a growth story, and the two _PRE columns are what let you say so from one file.

Its Locations tab also carries a choice the other reports do not: Total Enterprise or Location Attributes. Total Enterprise collapses geography entirely and returns one row per item per week for all of Kroger, which is a file measured in kilobytes rather than hundreds of megabytes. If the question is "what is our national digital mix", that is the setting, and picking Location Attributes instead is how a five-minute question becomes an overnight export.

The trap: UPC_ITEM_DESCRIPTION keeps its leading zeros and the UPC column does not. The first arrives as 0009999900123 - SUNRISE COOKIE OAT 12 OZ and the second as 9999900123. Joining the two as strings fails silently, and it fails in the direction that drops rows rather than duplicating them, which is the harder failure to notice.

Warehouse Inventory

Units of each case SKU sitting in each Kroger distribution centre, one row per day. Opened at Division Commodity level. The only report here that sees Kroger's own supply position rather than the shelf.

Warehouse Inventory answers a question none of the sales reports can: is the product actually in Kroger's building. A store that is authorized, selling nothing, and served by a DC holding zero units is a supply problem, and this is the report that separates that from a demand problem.

Its parameter panel is unlike the others. There are no Divisions and no Stores; geography is DCs, and that tab renders only after products are chosen. Dates are set on a Days tab with a day-range picker and quick picks rather than the fiscal-week control.

The grain is a distribution centre and a case SKU on a date, and DATE_KEY carries that date on every row, which makes this the one rolling-event report in the set.

Two traps, and the first is severe.

There is no consumer UPC in this report. The item is identified by CAS_SCN_CD_TX, a 13-digit case scan code, and CAS_SKU_CD, a five-digit Kroger warehouse SKU. Neither is the UPC that Sherlock, Store Authorization and Digital Performance all key on. You cannot join Warehouse Inventory to any other report in this guide by item without building a case-to-UPC mapping of your own, and nothing in OnDemand hands you one.

A zero in WHS_BOH is not always a zero. 84.51 does not expand the abbreviation or publish the unit, and its updates panel has posted at least one outage where missing inventory arrived as 0 or near zero rather than as an absent row. Treat a sudden run of zeros across a whole DC as suspect until you have checked the portal's own updates panel.

One smaller thing: the same DC is written three ways in the same file. RE_WHS_NUM_TX is 035, RE_WHS_DESC is SOUTHWEST - DALLAS, and DC_CODE_DESCRIPTION is 035 SOUTHWEST - DALLAS. Pick one and be consistent, because grouping by the wrong one gives a different DC count.

A worked example of what the report is for, on invented numbers. Sunrise Cookies has one case SKU showing WHS_BOH of 88 at one DC and 704 at another on the same day. The stores served by the first DC sold 210 units that week, and the item ships 12 to a case, so demand is 17.5 cases a week. Read those 88 as cases and the first DC holds 5.0 weeks of supply while the second holds 40.2, which is more than nine months. Read them as eaches instead and the first DC holds 88 divided by 210 of a week, which is under three days. The ranking is the same either way and the decision is not, which is why confirming the unit with your Kroger contact is worth doing once and writing down: 84.51 does not publish it, and the difference here is a factor of twelve.

Either way the imbalance is the finding, and it is invisible in every sales report on this page.

Two siblings sit beside it. Division Inventory and Store Inventory move the same question closer to the shelf, and Store Inventory is the one that answers "is it in the back room", which is the other half of an out-of-stock investigation: an empty shelf with stock in the building is a labour problem, and an empty shelf with nothing in the building is a supply one. The Days tab on this report also has a Weeks granularity beside Days, with Beginning Week and Ending Week dropdowns, if a daily series is more resolution than you want.

Out-of-Stock Weekly by Division

How many times an item was found with an empty shelf, per division per fiscal week, with the sales that represents. Opened at Division Commodity level. The availability report.

Every retailer has an on-shelf availability problem and most suppliers cannot size theirs. This report does, in EMPTY_SHELF_EVENTS, a count of empty-shelf detections for one item in one division in one week. The wider export also carries DOLLAR_OPPORTUNITY and UNIT_OPPORTUNITY, Kroger's own estimate of what those events cost.

It is division-level. There is no store column, and its grain is division plus ITM_SKU_CD. If you need store-level availability, Out-of-Stock Weekly and Out-of-Stock Daily exist at Store level in the library.

A worked example. Sunrise Cookies sees 285 empty-shelf events on one item in one division in one week, with a dollar opportunity of 1,710. That is an implied 6.00 per event, which is roughly one unit at shelf price, so Kroger's estimate here is closer to "one lost sale per detection" than to a full lost-day. Whether that is conservative depends on the item, and the ratio is worth computing on your own data before quoting the opportunity figure to anyone.

The trap: the report only lists items that had at least one event. The minimum value in live exports is 1, never 0. So a missing row means either perfect availability or that the item is not carried in that division at all, and the report cannot tell you which. Join to Store Authorization Detail to separate them, and remember that the two use different UPC forms.

There are three siblings and they answer noticeably different questions. Out-of-Stock Weekly is the store-level version of this report, which is what you want when the conversation is with a specific store rather than about a division. Out-of-Stock Daily is the tight-loop version for watching a fix land. On-Shelf Audit Report is a different measurement entirely: a physical audit rather than an inferred detection, so it is smaller, slower and more trustworthy per observation.

The distinction between "event" and "hour" matters for how you quote this. An empty-shelf event is a detection, not a duration, so 310 events is not 310 hours or 310 lost sales; it is 310 times a check found nothing there. Trend it against itself rather than converting it into a rate, and use DOLLAR_OPPORTUNITY when you need a number in currency. For the general measure, see on-shelf availability.

Item Distribution Summary

Planogram, distributor and last-sold detail per item and store. Not an OnDemand export. It arrives as a file from a Kroger contact and is uploaded, which is why it looks nothing like the reports above.

This one is included because it has a real name that a supplier will search for, and because it carries three things nothing else in this guide does: the planogram the item is on, which distributor delivers it, and when that store last sold it.

It is the report for direct-store-delivery categories, where a third-party distributor rather than a Kroger DC brings the product in. Distributor and Distributor Name identify who that is, and Last Delivery Date against Last Sold Date is the classic phantom-inventory pair: a store that was delivered six weeks ago and last sold four weeks ago either has stock nobody can find or has stock it did not need.

POG # is a structured planogram key rather than a plain id, and it encodes enough to be useful:

D531_L00000_D01_C099_VN99_F004_MX_H084_B31_U31_9999999

That instance is invented, but the shape is the portal's. The leading D531 is the division, D01 the department, C099 the commodity and F004 the facing count, with a planogram version and id on the end. Two rows differing only in the F segment are the same planogram at different facings, which is a distribution change worth catching. Treat the VN segment as a supplier identifier and strip it before sharing a real one outside your team.

Average Weekly $ Per Store Per Week Where Selling is the column to read carefully. The denominator is only the stores and weeks where the item actually sold, so it runs higher than a plain average across all stores. A worked example: an item sells in 26 of 38 stores, and averages 31.40 per selling store-week. Multiplying 31.40 by 38 overstates the division by nearly half. The column answers "how does it do where it works", not "what is it worth here".

One column divergence to know about: the file's header says Store # and Scout normalizes it to Store. Every other Kroger column in this guide keeps the portal's own header exactly.

Two more things this report does differently, both consequences of arriving as a file rather than as an export. Its dates are M/D/YYYY rather than ISO, so a date like 3/09/2026 sorts as text into the wrong order and needs parsing before it is useful. And it has no fiscal week at all: Last Update Date For POG is the only date describing the file as a whole, so the whole snapshot is anchored on the day the planogram was last revised rather than on a period. That makes it a snapshot in the sense of the refresh shapes above, with the same consequence: what it said last quarter is gone unless somebody kept the file.

Reading the numbers

Four things that decide whether the file you pulled means what you think it means.

Snapshot vs rolling-event

OnDemand reports come in three refresh shapes, and the difference decides whether a missed pull is recoverable. This is the one operational fact on this page that costs money if you get it wrong.

Windowed. The report takes a date or fiscal-week parameter, so any past period can be asked for again. Sherlock Store Matrix, Digital Performance Integrated and Out-of-Stock Weekly by Division are all like this. Miss a week and you can go back for it.

Snapshot. The report takes no date parameter at all. It returns the current state, and whoever stores it has to stamp it with a date of their own choosing. Scout snaps to a Saturday, which puts the stamp anywhere from four days before the pull to six days after it: a Wednesday pull is stamped the previous Saturday, and a Sunday pull is stamped the Saturday six days ahead. Reconcile an authorization history against pull logs on that window, not on the pull date. Store Authorization Detail is the snapshot here. A week nobody pulled is permanently empty, because there is no way to ask the portal what the state used to be. If you care about how your authorized store count moved over a year, the only way to have that history is to have been taking it.

Rolling-event. The report carries a date on every row and is pulled over a trailing window. Warehouse Inventory is this one, on a seven-day window, so a single missed pull heals itself on the next run as long as the gap is shorter than the window.

What that implies for a pull schedule is concrete. Store Authorization Detail has to be on a timer, because every week you skip is a hole you cannot fill later; weekly is enough for an assortment that moves at line-review pace. Warehouse Inventory wants a cadence shorter than its seven-day window, so weekly works and fortnightly quietly loses days. The three windowed reports can be pulled whenever you need them and backfilled afterwards, which means they are the ones to deprioritise when something breaks.

A worked example of the asymmetry. Miss four weeks of all five reports over a holiday. The three windowed reports are recovered by four re-pulls. Warehouse Inventory recovers the last seven days and loses the other 21. Store Authorization Detail recovers nothing at all: four snapshots that were never taken, and the only record of what your authorized store count did over that month is gone.

One qualification worth making, because "windowed means immutable" is not quite true. Kroger does restate. The portal announced in mid-2026 that third-party delivery history in the Digital Performance reports had been restated back to March 2025 to match new delivery-partner breakouts. Re-pulling an old week can therefore return different numbers than the first pull did, and for the digital reports that window has been over a year wide. Weekly volumes are otherwise stable enough to treat a complete week as settled.

Sell-in vs sell-through

Kroger is a retailer, so its reports are sell-through: what shoppers bought. That is the opposite of the distributor portals, where everything is sell-in, and it is worth stating because a supplier who works both is switching between two meanings of the word "sales" all week.

The practical difference is what a decline means. A drop in a distributor's shipment report can be inventory rebalancing with no change in consumer demand at all. A drop in SCANNED_MOVEMENT on Sherlock Store Matrix is fewer units leaving the shelf, and there is no warehouse effect to hide behind.

Kroger does carry one sell-in view, and it is Warehouse Inventory: what Kroger holds rather than what shoppers bought. Reading it beside Sherlock is how you separate "nobody wanted it" from "it was not there to want", which is a diagnosis you cannot make from either report alone.

A worked diagnosis, on invented numbers. Sunrise Cookies is down 18% in scanned units in one division week over week: 1,230 units against 1,500. Three reports answer three different questions about that. Store Authorization Detail says the item is still authorized in the same 190 stores, so it is not a delisting. Out-of-Stock Weekly by Division says empty-shelf events went from 45 to 310, which is nearly seven times as many. Warehouse Inventory says the serving DC went to single-digit WHS_BOH mid-week. Those three together say the decline is a supply failure, not a demand one, and the 270 missing units are recoverable. The same 18% with flat out-of-stocks and healthy inventory would be the opposite conclusion and a different conversation entirely.

That is the argument for pulling all five reports rather than the one that answers today's question: a single number is a symptom, and the diagnosis needs the others.

For the general form of this distinction, see consumption vs shipment data.

The modality grid

Digital Performance Integrated splits every measure by modality, meaning how the shopper bought. That is a grid: five modalities times four measures times two periods, which is where 40 of its 72 columns come from.

The Measures panel offers six modalities: Total, Fuel Center, Seamless Pickup, Seamless Delivery, Express Delivery, and Seamless Pickup & Delivery combined. "Seamless" is Kroger's own word for its e-commerce fulfilment. Note that Express Delivery is in the panel and has no matching column in the standard export set, so ticking it is not the same as getting it.

The measures beside them are Seamless Digital Penetration, Scanned Retail $, Scanned Movement, Gross Margin $, Gross Margin Rate, Average Price and Lbs. Three of them, Scanned Retail $, Scanned Movement and Gross Margin $, come in four forms: Current, Previous, Change and % Change. The ratios come in fewer. Either way that is more than the exports usually carry: a standard pull returns _CUR and _PRE and leaves you to compute the deltas. Penetration, margin rate and average price are ratios, and a ratio cannot be summed across rows, so those three are the ones to recompute from the dollar and unit columns rather than average.

The thing to know before building anything on this: a modality column is present in the export whether or not you ticked that modality in the Measures panel, and an unticked one arrives empty rather than as zero. In live exports it is normal to see TOTAL_* and SEAMLESS_PICKUP_AND_DELIVERY_* populated and the individual Pickup, Delivery and Fuel Center columns entirely null, because that is what was selected. An empty column here means "not requested", not "no sales", and the two lead to opposite conclusions.

Note also that Pickup and Delivery are separately available and available combined, and the combined column is not always the sum of the two you have, because you may not have pulled both. Take the combined column when you want the digital total; do not add.

A worked example of why not to add them, on invented numbers. One week returns TOTAL_SCANNED_RETAIL_DOLLARS_CUR of 12,400 and SEAMLESS_PICKUP_AND_DELIVERY_SCANNED_RETAIL_DOLLARS_CUR of 3,100, with the individual Pickup and Delivery columns empty because they were not requested. Digital share is 3100 divided by 12400, or 25.0%, and in-store is the remainder, 9,300. Add the empty Pickup and Delivery columns to the combined one and you get 3,100 again if your tooling treats null as zero, or nothing at all if it does not, and neither result tells you it was built on absent columns rather than on zero sales.

One further wrinkle from the portal's own updates: the delivery breakout now distinguishes third-party partners, named as DoorDash, Instacart, UberEats and Shipt. If your pipeline was built before that change, its delivery history was restated underneath it, so a chart of digital mix that runs back past early 2025 may not match the version of it you saved last year.

Only my products

At the Commodity and Subcommodity steps of the Products tab there is a checkbox labelled Only my products. It is one checkbox and it decides whether your export is your brand or your entire category.

Leave it unchecked and the report returns every item in the selected commodities, including every competitor. Tick it and the export narrows to the items you supply.

No other control in the portal changes the file this much, and it is easy to leave in the wrong state, because nothing downstream announces which way it was set. It is worth stating flatly: if you want category context, do not tick it.

What you get by leaving it unchecked is genuinely unusual. Most supplier-facing retailer portals show you only your own items; this one will hand you competitor-level scanned dollars and units at store granularity for a whole Kroger category. That is the basis for real share work, and MFR_CD and MFR_DESC are how you split it by manufacturer.

A note on MFR_CD, because it explains why the competitor rows are there at all: it is the UPC company prefix, zero-padded to eight digits, derived from the UPC itself. It is not a Kroger vendor number. That is why every manufacturer in the category carries its own, and it is also why two brands owned by the same company can carry different MFR_CD values while sharing a PARENT_OWNER_DESC.

The cost is size, and it is not a small multiple. On invented but representative numbers: a brand with 9 items in a category of 2,250 gets 250 times the rows for the same store and week coverage. A whole-category, all-division, store-level weekly pull is therefore hundreds of thousands of rows per week rather than the low thousands, and the digital equivalent at UPC by store grain runs into hundreds of megabytes per export.

So scope by commodity rather than by department, and pull the category cut on the cadence you actually use it at. A weekly brand-only pull plus a monthly category pull is usually the right trade; a weekly whole-department pull is a file nobody opens.

Getting the data out

Data Only vs Grid

The export dialog defaults to Grid. For three of the five reports in this guide, Grid is the wrong answer, and it is wrong in a way that produces a file that looks fine.

Warehouse Inventory, Out-of-Stock Weekly by Division and Digital Performance Integrated render as pivot grids. Their on-screen display pivots weeks into columns and moves division, manufacturer, commodity and subcommodity into the filter area. A Grid export writes out that display: wide, week-as-column, and aggregated across the dimensions the pivot parked. What comes out has a UPC, an item description and a column per week, and it is not the data.

Data Only exports the flat underlying rows instead: the long, per-division, per-item feed with every dimension still on the row. That is the file you want, every time, for anything you intend to load somewhere.

The width difference is the quickest way to tell which one you got. Data Only lands at roughly 12 columns for Out-of-Stock Weekly by Division, 14 for Warehouse Inventory, 20 for Store Authorization Detail, 30 for Sherlock Store Matrix and 72 for Digital Performance Integrated. A Grid export of any of the three pivot reports arrives with three or four dimension columns and then one column per week. If your file has a column called something like 2026 PD 05 WK 1 (17), you exported the display.

Sherlock Store Matrix is not a pivot, so Grid and Data Only produce the same thing there. That is exactly why this trap is easy to fall into: the first report most people export is the one where the setting does not matter, and the habit carries into the three where it does.

There is a second checkbox in the same dialog, Include Header. Leave it off. Off gives a clean CSV whose first row is the column names. On adds the report's own parameter banner above the header row, so the file's first line is not the header and most loaders will get the columns wrong.

Both settings are per-export and neither is remembered, so they are worth checking every time rather than once.

What the export does not carry

The CSV is honest about what it contains and silent about how it was made, and the silence is where the problems come from. None of the following is in the file:

The report level. A Store Commodity export and a Store GTIN Group export of the same report name are different files with no marker distinguishing them.

Fiscal Weeks or Ad Weeks. The dates land as week names either way, and nothing records which radio button produced them.

Only my products. A category pull and a brand pull look identical in structure; only the row count and the manufacturer spread differ.

The Consumer UPC or Base UPC choice. The column is called UPC in both cases.

When it was pulled, on the snapshot report. Store Authorization Detail has no date anywhere in it.

The consequence is that a Kroger export is not self-describing, and two files that will not reconcile usually differ in one of the five choices above rather than in the data. Put the settings in the filename, or record them beside the file. A convention that works, in order: report, level, week, and whether it is category or brand scope.

ssm_store-commodity_2026-PD05-WK1_category.csv
oos_division-commodity_2026-PD05-WK1_brand_baseupc.csv
storeauth_store-commodity_pulled-2026-09-14_category.csv

Note the third one. A snapshot has no period of its own, so the date in its name is the day it was pulled, and writing pulled- in front of it is what stops somebody reading it a year later as the week it describes. That single prefix is the difference between a usable archive of authorization history and a folder of files nobody trusts.

For very large pulls the report may not render on screen at all, showing a notice about a large amount of data instead. The Export button still works in that state, and the file is complete. A whole-category store-level pull normally lands there.

Where Scout fits

Scout is a demand-side analytics layer. It does not grant access to OnDemand, it is not a Kroger portal, and nothing here replaces the entitlement your account team gives you: you sign in with your own credentials and pull your own reports, exactly as described above.

What Scout does is the part after the export. It takes those CSVs, keeps their column names as 84.51 wrote them, resolves the fiscal week names into calendar periods so a Kroger week can be compared with anything else, and holds the history that the snapshot reports otherwise lose. The column tables throughout this guide are generated from that same catalog, which is why they match what lands in the file rather than what a document once said.

Three of the traps on this page are the ones worth automating out rather than remembering: the fiscal-week conversion, because it is arithmetic nobody should do twice; keeping a dated copy of Store Authorization Detail, because the history is unrecoverable if you do not; and holding the case-code-to-UPC mapping that Warehouse Inventory needs, because building it once is the difference between four joinable reports and five.

If it is useful to have Kroger sitting beside your syndicated data and your distributor feeds in one place, that is the problem Scout works on. If it is useful to know what RPT_SHORT_DESC means at four in the afternoon before a line review, this page was the point.