KeHE CONNECT Supplier: reports and columns

Everything in the KeHE CONNECT Supplier portal is sell-in. KeHE buys your product, warehouses it across roughly twenty distribution centres, and ships it to retail chains. It never touches a register, so it cannot see a single consumer purchase. Every number labelled "sales" in this portal is what retailers ordered from KeHE, not what shoppers bought.

That distinction is the most expensive misreading in the category, and it is worth being blunt about it before naming a single report. A brand that reads "sales down 12%" in CONNECT and concludes that demand fell has made an error that a distributor's data physically cannot support. Retailers might have ordered less because they were overstocked from last month. A distribution centre might have been out of stock. A chain might have shifted to direct delivery. All of those move this number and none of them are demand.

What the portal is genuinely excellent at is the supply chain between you and the shelf: what KeHE holds, where, how old it is, which stores are carrying you, which stores stopped, what KeHE expects to order next, and what it deducted from your last cheque and why. This guide covers all eighteen reports, the four CONNECT BI dashboards, and the concepts that decide whether the numbers you pull are the numbers you think you pulled.

KeHE ships no data dictionary. The Help Center has training videos and pricing FAQs, and nothing at the report or column level. Everything below was recorded from the portal itself.

How KeHE CONNECT Supplier works

Before any report makes sense, you need to know where in the flow of goods and money it was measured. Four positions, and every report sits at exactly one.

The four-position pipeline

KeHE is a distributor, not a retailer and not a broker. It takes ownership of your product, holds it in its own warehouses, and sells it on to retail chains. That ownership is why the portal can tell you about inventory at all, and why it bills you for things a retailer never would.

The four positions are worth naming because they answer different questions and fail in different ways:

1. Brand into KeHE. Did you deliver what KeHE ordered, on time? One report, Inbound Fill Rate, and it is the only report in the portal that measures you rather than the retailer.
2. Inside KeHE. What is in the warehouse, where, how old, and how fast is it moving? Six reports, all current-state snapshots.
3. KeHE out to retailers. What did chains order, what shipped, where are the gaps? Eight reports. This is where the sell-in ceiling applies.
4. Money between KeHE and you. Invoices, credits, deductions, cheques. Two reports, on two different portals.

A number that surprises you is usually a number you have placed at the wrong position. Shipments to retailers fell, but is that a demand problem (position three, invisible), a warehouse availability problem (position two), or a delivery problem on your side (position one)? The portal can separate those, but only if you know which report sits where.

The retailer hierarchy

KeHE organises its customers into four levels, and almost every sales report carries all four as separate columns. Getting the level wrong is the second most common way to misread this portal, because a count at the wrong level is still a plausible-looking number.

The levels, widest to narrowest:

"How many accounts do we have at KeHE" has four different right answers depending on which of these you count, and they can differ by an order of magnitude. A brand in four retailer parents can be in ninety stores.

Two traps. First, All Other is a real value, not a select-all: it is KeHE's bucket for stores it has not categorised into a parent. Filter it out and you drop real volume; treat it as a total and you double-count. Second, the column names above are how the portal's own structural FAQ names the levels, and they are not always the header on the export. Most reports do use exactly these spellings. Gap Void Sales does not, and that is covered in its own section.

Two portals, three surfaces

KeHE's supplier data lives behind two separate logins, and the reports come in three different shapes. This trips people up because "the KeHE portal" is not one thing.

CONNECT Supplier (connectsupplier.kehe.com) hosts two of the three surfaces:

• The Connect Data reports. Seventeen flat, tabular reports rendered in an embedded report viewer, each with its own parameter panel, each exporting to CSV. These are the bulk of this guide.
• The CONNECT BI dashboards. Four visual, chart-driven dashboards under Connect Analytics. Different technology, different filter model, and they cover only a fraction of what the flat reports do. Covered in their own group.

Legacy CONNECT (connect.kehe.com) hosts the third:

• K-Solve, the deductions grid. A separate login, a separate session, and an Excel export rather than a CSV. If you are looking for deductions and cannot find them in CONNECT Supplier, this is why.

The practical consequence is that a complete picture of your KeHE business requires signing into two systems, and nothing joins them for you.

Which surface to reach for, by question:

The rule of thumb: if you want a number in a spreadsheet, use the flat reports. The dashboards are faster to read and cannot be exported into anything you can join.

Reading a parameter panel

Every flat report opens on a parameter panel rather than on data. Picking values and clicking View Report is what generates it, and the panel has three behaviours worth knowing before you fight with one.

Parameters cascade. Choosing an Enterprise Supplier repopulates everything below it. Until you have chosen one, the dependent dropdowns are genuinely empty, not merely unfiltered. That is why a report can look broken on first load: it is waiting for you.

The lists are scoped to you. Once the cascade runs, a dropdown shows only values you have data for. The Channel list is not every channel KeHE recognises, it is every channel you ship into. This is convenient and it means you cannot use the panel to learn KeHE's full vocabulary for anything.

A third behaviour is easier to hit than to diagnose. Several reports render a required multi-select as a text box with a dropdown arrow, which does not look required at all. Leave one untouched and the report renders its parameter panel and no body, with nothing on screen naming the field you missed.

Parameters are also where the fiscal calendar bites. Reports that ask for a Fiscal Year and Fiscal Period are on KeHE's calendar, which starts in May. Reports that ask for a Calendar Year and Month are on the ordinary one. Both kinds exist in the same picker, and mixing them is silent.

A worked sequence, on Gap Void Sales. Open the report and ten dropdowns are visible, nine of them empty. Pick the Enterprise Supplier and the panel posts back; retailer parent, area, retailer, channel, state, category, brand and GBB all populate at once, restricted to values that supplier ships. Leave them alone and the report runs across everything, which is usually what you want. Narrow one and the ones below it narrow again. The whole panel is a single cascade, so changing the supplier at the end discards every choice you made after it.

Brand to KeHE: what arrived

One report sits at the inbound position, and it is the only one in the portal that grades you rather than a retailer.

Inbound Fill Rate

Of what KeHE ordered from you, how much actually arrived. Daily snapshot, one row per item, with ordered against received, the resulting fill rate, and how many days off the delivery was. The only report here that measures the brand.

This is KeHE's scorecard of you as a supplier, and it is the report your account manager is looking at when a conversation about service levels starts. A low inbound fill rate is a supply problem you own, and it propagates: units KeHE never received are units it cannot ship, which shows up two positions later as lost distribution you might otherwise blame on the retailer.

A worked example. KeHE orders 1,296 units of one Sunrise Cookies item across a month and receives 1,152. The fill rate is 1152 divided by 1296, which is 0.8889. Note the form: this column is a fraction, not a percentage. A value of 0.8889 means 88.89%, and a dashboard that renders it as "0.89%" has treated it as one.

The trap in this report is what it does not have. There is no UPC column. The item is identified only by Product, a single string that runs the pack size, unit of measure and description together, something like 12 FO WATER SPK ACV BERRY PEAR. Every other report in the portal keys on UPC. This one cannot be joined to any of them by item without matching on description text, which is fragile and which nobody should build a pipeline on.

DaysEarlyLate carries a second, smaller trap: KeHE does not document the sign convention, and in the data observed only positive values appear. Treat it as a magnitude and confirm the direction with your account manager before reporting it as lateness.

OffInvAmt is the allowance deducted from the purchase order before KeHE pays it, which is the off-invoice half of off-invoice vs billback.

Grain is one row per item per snapshot. There is no date parameter, so the report is current-state and stamped with the day it was pulled. Refresh is daily, with KeHE's own data landing by about 9am Central.

Inside KeHE: inventory and placement

Six reports describe what KeHE is holding and where. All six are current-state snapshots with no date parameter, which has a consequence covered in snapshot vs windowed: a day you did not pull is a day you cannot recover.

Inventory Stock Status

What KeHE holds and what is on order, per item and distribution centre, with weeks of supply at the current rate of sale. Daily snapshot. The report to open when you want to know whether KeHE can actually service demand next week.

This is the workhorse inventory report. For each item at each DC it gives units on hand, units on purchase order from you, units committed to retailer orders not yet shipped, and weeks of supply for both on-hand and on-order.

It also carries pre-computed rollups at three levels above the item: whole report, brand, and distribution centre. Those columns are stamped onto every leaf row, so SUM(TotalQuantityOnHand) does not give you the total, it gives you the total multiplied by the number of rows. Aggregate the unprefixed leaf columns and nothing else. This pattern recurs across the portal and has its own section.

A worked example on weeks of supply. Sunrise Cookies has 1,404 units of one item on hand at a single DC and is selling roughly 39 units a week through it. Weeks on hand is 1404 divided by 39, which is 36 weeks. That is a genuinely overstocked position and the number reads sensibly.

Now the trap. Take the same 1,404 units at a DC where the item sells 1.5 units a week and weeks on hand is 936. Values in the hundreds and low thousands appear regularly in this column, and they are arithmetic rather than corruption: as velocity approaches zero the quotient explodes. Any alerting you build on weeks of supply needs a velocity floor underneath it, or every slow item at every DC will page you forever.

The general measure is days of supply; KeHE reports it in weeks.

One more oddity: the export carries a column called textbox31 that is blank on every row. It is a layout artifact of the report viewer, not a field you are missing the meaning of.

Aged Inventory by Brand

How long KeHE's stock of your brand has been sitting, bucketed by age, at brand, DC and item level. Daily snapshot, but gated behind a fiscal year and period cascade in the parameter panel.

Age matters because KeHE guarantees its retail customers a minimum remaining shelf life. Stock that has aged past the point where it can meet that guarantee cannot ship, and becomes a conversation about who absorbs it. This report is the early warning; Inventory at Risk is the alarm.

The buckets run 30, 60, 90, 120 and 365 days, with an over-365 bucket at the end. Each appears three times, once as an item-level figure at a distribution centre, once rolled up to the brand, and once rolled up to brand within DC. Both rollup families repeat on every row, with the same warning as above.

Two things to know before you use it. First, the parameter panel asks for a Fiscal Year and Fiscal Period even though the output is a current-state snapshot, so you have to know which fiscal period you are in to pull it at all. Second, KeHE spells the ninety-day bucket Ninty, and it appears that way in every column name for that bucket. It is not a typo you can code around; it is the column name.

A worked example. Across one DC, Sunrise Cookies shows 48 units in the 30-day bucket, 36 in the 60-day, and 12 in the over-365 bucket, with a total of 96. The last twelve units are the ones to act on: they have been in the warehouse over a year, they will not meet any shelf-life guarantee, and they will eventually appear as a spoils deduction rather than as a sale.

Inventory at Risk

Units KeHE is holding that its own forecast has no demand for, with the shelf-life deadline attached. Daily snapshot, one row per item and distribution centre. The report that tells you that you are about to be asked to take product back.

Where Aged Inventory tells you how old the stock is, this one tells you it is not going to move in time. It combines four things KeHE knows and you do not: the sell-by date, the shelf life it has guaranteed to the receiving retailer, the recent daily sales velocity, and the number of units its forecast cannot place.

The key column is DaysRemainingToShipToCustomer, and it is not the same as days until the sell-by date. If KeHE guarantees a retailer 30 days of remaining life and an item's sell-by date is 45 days out, the shipping deadline is 15 days away, not 45. Stock that crosses that line stops being sellable through KeHE even though it is still perfectly good product.

A worked example. A Sunrise Beverage item has 936 units on hand with no forecast demand, a sell-by date 60 days out, and a 30-day guarantee. That gives 30 days to ship. Velocity is 4.85 units a day, so the run rate would clear 145 units in that window. The other 791 units are the exposure, and the conversation to have now rather than in a month.

Reason and Note are single-character codes. KeHE does not document either vocabulary anywhere in the portal, and the catalog reflects that rather than guessing at them.

Brand Item Location

Which KeHE distribution centres stock which of your items, with the pack, price and status KeHE holds for each. Snapshot. The reference table for your item setup, and the place to check when a DC will not order something.

It reads as a configuration dump rather than an analytics report, which is exactly what makes it useful. If a chain says it cannot get an item, this tells you whether the item is even set up at the DC that serves them.

It carries KeHE's own item numbers, the case barcode, the list wholesale price and the suggested retail price, plus pack and size. CaseBarcode is the shipping case GTIN-14 built from the consumer UPC with a leading indicator digit and a recomputed check digit, so it is not the UPC with zeros bolted on the front and string-matching between the two will not work.

A worked example. A Sunrise Cookies item has a consumer UPC of 198168190524 and a CaseBarcode of 20198168190528. The case code is not the UPC with 20 bolted on the front: it is a GTIN-14 built from an indicator digit, a leading zero, the UPC's first eleven digits, and a check digit recalculated across the whole fourteen. The final digit changes from 4 to 8 because of that recalculation, which is exactly the character a substring match would rely on.

Pack and MasterPack are the two levels of packaging KeHE tracks; the general form is case pack.

Two columns are misleading by name. Jobber is a price, not a person or a company, and it is stored as text rather than as a number. And LocationItemNumber and KeHENumber were observed carrying identical values; KeHE does not document how the two are meant to differ.

StatusCode and FreightMethod are both short codes whose full vocabularies KeHE does not publish. Only a handful of values appear in any one account, so you cannot infer the set from your own data either.

Item 360 Recap HD

A single-item dashboard whose Type parameter swaps which metric family renders, spanning inbound, inventory and outbound in one report. Snapshot, keyed on item and distribution centre.

The Type parameter offers On Hand, Outstanding PO, Out of Stock, Purchases and Sales, and each returns a different set of measures for the same item. That makes it the one report in the portal that crosses positions, and it is why it sits here rather than in a sales group.

It is also structurally odd, and you should know that before you open the export. The report renders as label and value pairs rather than as a normal table. The export carries columns named textbox14, textbox3, textbox15 and so on, where the odd ones hold a constant label like "Sales WTD" and the even ones hold the number that goes with it. It reads perfectly on screen and looks like nonsense in a spreadsheet.

The trap that costs the most time is the identifier. The column is called UniversalProductCode, and it is not a UPC. It concatenates the UPC, the brand and the description into one string. Parsing it as a UPC yields nothing, and joining on it silently matches no rows.

A worked example of the layout. One row of the export reads textbox14 = "Sales WTD", textbox3 = 12, textbox15 = "Sales MTD", textbox4 = 144, textbox16 = "Sales YTD", textbox5 = 996. Three labels and three numbers, interleaved across six columns whose names carry no meaning. The item sold 12 units week to date, 144 month to date and 996 year to date. Any pipeline reading this report has to map the value textboxes to the labels beside them, and that mapping is positional rather than guaranteed.

KeHE Full POD Vendor

Full points of distribution: every store carrying each item, with this year against last year, for one calendar month. The widest store-level report in the portal, and the one to use for a distribution audit.

POD stands for points of distribution, a count of store and item combinations. This report gives you the underlying rows rather than the count, so you can see exactly which stores carry which items and what each shipped, along with the full retailer hierarchy, the store address, and KeHE's five-level product classification.

Note the period: this report is calendar-monthly, not fiscal. It asks for a Calendar Year and Month. Sitting two rows away in the same report picker are reports keyed on KeHE fiscal periods, and joining the two on a period number lines up the wrong months.

Now the structural surprise, and it is a big one. Sixteen of this report's forty-eight columns are not data. They are the report's own parameter banner, flattened into columns and repeated on every row. Eight of them are constant labels, so the column named Description contains the literal word "Description" on every row, and Vendor contains the word "Vendor". The other eight hold the parameters you chose, such as the DC filter and the store filter.

Real data starts at Channel. The one banner column worth reading is DateRangeSelected, which is how you tell which month a row belongs to, since the report does not otherwise carry a date.

A worked example on the year-on-year columns. A Sunrise Cookies item shows 48 units and $258.72 of vendor cost this year against zero last year, and YoYQtyChangePercent reads 100.0 %. That column is text, not a number: it carries a space and a percent sign, so it needs parsing before it will sort or sum. A brand new item will always show 100% growth against a zero base, which is arithmetically true and analytically empty.

KeHE to retailer: sales and assortment

Eight reports describe what KeHE ships out and where the holes are. Every one of them is sell-in. They are the best view you will get of your KeHE business, and none of them is a measure of consumer demand.

Chains and Stores that ordered an Item

What each chain and store ordered from KeHE against what actually shipped, with fill rate at every level of the retailer hierarchy. Monthly, weekly or daily. The widest sell-in report in the portal, and the one most worth learning well.

Reach for this one when the question is "who is buying us and how much". It resolves all the way down to store and item, and it carries ordered, shipped, fill rate, a store count and a SKU count at five levels: whole report, retailer parent, retailer area, retailer, and store.

Those five levels are the report's power and its main hazard. Every level's totals are stamped onto every leaf row, so a naive sum over RetailerParentTotalShipped multiplies that parent's total by the number of item and store rows underneath it. The leaf columns, the ones with no level prefix, are the only ones safe to aggregate.

A worked example on outbound fill rate. Sunrise Market's Midwest banner orders 900 units of a Sunrise Cookies item across a month and KeHE ships 828. Fill rate is 828 divided by 900, or 0.92. Those 72 unshipped units are a KeHE availability problem, not a demand problem: the stores wanted them. Cross-reference against Inventory Stock Status for that DC and you will usually find the reason.

Unlike most of the portal this report supports more than one period grain, so check which one you pulled before comparing two exports. A weekly and a monthly pull of the same period are both correct and are not comparable.

Enterprise Supplier Brand Channel Sales by State Detail

KeHE shipments for one fiscal period cut by brand, distribution centre, channel, state and item. Fiscal-monthly. The geographic and channel view of your sell-in, and the report behind most CONNECT BI sales visuals.

Where Chains and Stores answers "who", this answers "where" and "what kind of retailer". Channel is KeHE's classification of the retail format, and state is the shipping destination, so together they tell you whether growth is coming from a region, a format, or a single chain.

The period is fiscal, not calendar. It asks for a Fiscal Year and one or more Fiscal Periods, and KeHE's fiscal year starts in May. A report labelled fiscal 2027 period 1 covers May 2026.

Like its siblings it carries rollups, here at four levels above the item: whole report, brand, DC, channel and state. Same rule, aggregate the leaves.

A worked example. Sunrise Cookies ships 3,600 units into the Grocery Independent channel across two states in one fiscal period, at $19,404 of vendor cost. The per-state split is 2,400 units in one and 1,200 in the other. Summing StateTotalQtyShipped across the item-level rows would return far more than 3,600, because each state's total is repeated on every item row within it.

Enterprise Supplier Brand Sales Summary

Brand-level sell-in rollup for one KeHE fiscal period: ordered, shipped, vendor cost, discounts, credits and points of distribution. Fiscal-monthly. The one-screen answer to "how did the brand do last period".

This is the summary sibling of Sales by State, and its value is that it already carries the arithmetic you would otherwise do yourself. AdjCost is VendorCost less TempDiscount, so you can see gross and net side by side without reconstructing the promotional allowance.

POD is the count of points of distribution, meaning store and item combinations carrying the item. It is the single best distribution metric in the portal because it moves for reasons you can act on: an item lost from a chain drops it, a new banner picks it up.

A worked example. One Sunrise Cookies item shows 900 units ordered, 900 shipped, $4,851 of vendor cost, a $0 temporary discount and a POD of 71. Ordered equalling shipped is a perfect fill rate. A POD of 71 against 88 stores in the account means 17 stores are not carrying it, which is precisely the whitespace that Gap Void Sales exists to name.

Enterprise Supplier Chain Sales by Brand

Sell-in cut by retail chain and distribution centre for one KeHE fiscal period. Fiscal-monthly. The chain view of the same shipments Sales by State cuts geographically.

If you manage business by account, this is your report. It carries the retailer hierarchy down to subbanner, the DC that served each, and ordered, shipped, vendor cost and credits per item.

It is also the report to cite when you need the retailer hierarchy column names exactly as they appear in an export, because this one uses the canonical spellings: RetailerParent, RetailerAreaName and RetailerName. Most reports do. Gap Void Sales is the exception.

StoresThatOrderedAnItem gives you the store count per chain and item, which is the distribution number your account manager will quote. It is a count of stores that ordered in the period, not a count of stores authorised to, and the difference between those two is the gap.

Gap Void Sales

Stores that carry your other items but not this one, plus stores that used to order it and stopped. Current-state snapshot, one row per store and item. KeHE's whitespace report: the distribution you could have and do not.

This is the most directly actionable report in the portal. Every row is a specific store, with its address, that a specific item is missing from. A gap is a store carrying the brand but not the item; a void is a store that ordered the item and has lapsed. Both are a sales call.

The money column is cogsl52, cost of goods sold over the trailing 52 weeks. It is the prize attached to closing the gap, sized from the account's own recent history. Note that it is a trailing-year figure, not a figure for the snapshot period, so it does not sum with anything in the monthly sales reports.

A worked example. Sunrise Market's Midwest banner has 24 stores carrying Sunrise Cookies, of which 18 carry the sea salt item. The report returns 6 rows for that banner, each naming a store, with a trailing-52-week COGS of about $1,100 each. That is roughly $6,600 of annualised distribution sitting in six sales calls.

Now the trap that is unique to this report. Gap Void Sales is the one KeHE report whose export headers are lowercase. Where every other report gives you RetailerParent, this one gives you retailerparent. The portal's own structural FAQ names the level RetailerParent, so documentation and export disagree, and a case-sensitive join across two reports will silently match nothing. The reference table below shows the headers exactly as the export carries them.

One further caution: this report is empty for a supplier with no current gap or void activity, and an empty export is a legitimate result rather than an error.

A gap here is a distribution gap rather than an out-of-stock; for the shelf-level measure see on-shelf availability.

AL for ESN Chain Group

The authorisation list: which of your items a chain has approved for its stores to order. Current-state snapshot, one row per authorised item. Short, and easy to misread as distribution.

Authorisation is permission, not presence. An item on this list is one that stores in the chain are allowed to order. It says nothing about whether any of them have. The gap between this list and what Chains and Stores shows actually ordering is the single most useful derived number in the portal, and neither report computes it for you.

A worked example. Sunrise Cookies has 7 items authorised at one retailer parent. Chains and Stores shows 5 of them ordered by at least one store in the period. The other 2 are authorised, sellable, and in nobody's order guide. That is a different problem from a gap, and a different sales conversation.

The export is unusually thin: UPC, brand and description, and little else. The parameters carry the context, so record which retailer parent and area you ran it for, because the export does not tell you.

For the general concept see assortment; an authorisation list is one distributor's implementation of it.

AOM Inventory Gap

Coverage gaps by account: where an order is expected and the inventory to serve it is not in place. Current-state snapshot, keyed on UPC, account and distribution centre. This is the one report in the portal whose CSV export does not work.

It is worth documenting anyway, because the same data is available through the AOM Inventory Gap dashboard and because the export failure has a specific, understandable cause.

The parameter panel cascades Enterprise Supplier into Brand, then presents four multi-select popups: distribution centre, account name, UPC, and Coverage Status. Coverage Status has exactly two values, Inventory Gap and On Track, and that pair is the whole point of the report: it splits accounts into those KeHE can currently serve and those it cannot.

The export fails because the large multi-selects require an explicit, committed selection and the report will not render its body without one. It renders its parameter panel and stops, with no error naming the field. If you need this data as a file today, the dashboard is the route.

Because the report has never exported, KeHE's column list for it has never been captured, so there is no reference table below. The dashboard's detail view shows coverage status, DC, account, requested dollars and quantity, quantity on hand, quantity on order, shipped quantity, UPC, brand, description, event start date and buyer.

KeHE 30x20

A matrix of your top 30 selling items against the top 20 retailer parents for one calendar month. Calendar-monthly, not fiscal. A quick concentration read rather than an analytical dataset.

The report answers one question well: how concentrated is the business. If two retailer parents account for most of the volume across most of the top items, that is a risk worth naming before a buyer changes.

Two structural notes. It is calendar-monthly, so it does not line up with the fiscal-monthly sales reports without translating the period. And the export carries the report's banner and spacer rows, so a handful of rows arrive with a blank retailer parent and a null rank and quantity. Filter on a non-null Rank before doing anything with it.

RetailerParentCompanyName is a constant label column holding the literal phrase "Retailer Parent Name", not a company name. The actual parent is in RetailerParentName.

Deductions, credits and getting paid

Deductions are where brands lose money they cannot explain, and KeHE's deduction data is the least documented part of the least documented portal. Two reports cover it, on two different systems, and between them they answer some questions and conspicuously fail to answer others.

K-Solve credits

Processed deductions, credits, and the cheques that settled them. One row per transaction, on a rolling 90-day window. Lives on the legacy CONNECT portal, not CONNECT Supplier, and exports to Excel rather than CSV.

K-Solve is the deduction ledger. Every row is money that has already moved: a fee taken, a chargeback applied, a credit issued, and the cheque number that settled the batch it belonged to. If you are reconciling a short payment, this is the report that explains it.

Invoice Amt carries the direction. Negative is money taken from you and positive is an invoice or credit in your favour. A row reading -$350.00 with a Remarks of "April 2026 Publication Fees" is a fee, already deducted.

Two columns are batch-level and repeat down the report: Check # and Check Amt. One cheque settles many deductions, so the same cheque total appears on every row it paid. Summing Check Amt multiplies the payment by the size of the batch, which is a mistake that produces a very convincing wrong number.

Two more traps worth knowing before you build anything on the export. The ESN column drops the leading zero the portal displays, so an ESN copied from a parameter panel elsewhere will not join to it without padding. And Check Date carries both Excel serial numbers and ISO timestamps in the same column, so no single parse handles every row.

Open AP Supplier Statement

Open and outstanding items KeHE owes you. Current-state snapshot, one row per document, a single Enterprise Supplier parameter and nothing else. The unsettled sibling of K-Solve.

The pairing is the thing to understand. K-Solve carries what has been processed; Open AP carries what has not. A deduction in flight appears here, and moves to K-Solve once it settles. Reconciling a payment usually means reading both.

DollarAmount has a formatting convention that catches people: a credit is shown in parentheses, not with a minus sign. A value rendered as (350.00) is negative 350. Any parser that treats the parentheses as decoration gets the sign backwards, which is worse than failing.

A worked example of the sign convention. Three rows read 1,250.00, (350.00) and 900.00. Read naively that is 2,500. Read correctly it is 1250 minus 350 plus 900, which is 1,800, and TotalBalance on every row will say 1,800. If your total disagrees with the column by exactly twice one of the values, you have parsed a parenthesised credit as a positive.

TotalBalance is the statement total repeated on every row, with the same multiplication hazard as K-Solve's cheque columns.

The portal's on-screen labels for this report differ from the export headers. The screen shows Supplier #, Special Payee #, Enterprise Supplier #, Dollar Amount and Document #; the export gives you SupplierNumber, SpecialPayeeNumber, EnterpriseSupplierNumber, DollarAmount and DocumentNumber. Same fields, and the reference table below uses the export's spelling because that is what you will be holding.

What a KeHE deduction is

A deduction is money KeHE keeps rather than pays you, taken against an invoice you have already earned. It is not a bill you receive and choose to pay. It arrives as a smaller cheque, and the explanation is a code in a report you have to go looking for.

This is the structural difference between a deduction and an invoice, and it is why deductions get out of hand quietly. Nobody has to approve one on your side. The money is simply not in the payment, and the only trace is a row in K-Solve with a reference string on it.

Deductions at a distributor fall into roughly four families:

• Trade and marketing. Promotional allowances, advertising programmes, show and booth fees, new item setup fees. These are usually contracted, and the deduction is the mechanism by which you pay for something you agreed to. A new item setup fee is a distributor's version of a slotting fee.
• Chargebacks. KeHE recovering a cost it says you caused, such as a margin guarantee shortfall. A manufacturer chargeback is the general form.
• Spoils and damages. Product that could not be sold, charged back to you. These trace directly to Inventory at Risk and Aged Inventory by Brand, which is why those two reports are worth watching before the deduction arrives.
• Corrections. Rebills and adjustments against an earlier transaction.

A worked example. Sunrise Cookies invoices $4,851 for a fiscal period. The cheque arrives at $4,145.49. The $705.51 difference is three K-Solve rows: a $350.00 publication fee, a $304.68 promotional allowance, and a $50.83 spoils charge. None of those was refused; all three were simply netted out of the payment.

KeHE deduction codes

The reason for a deduction is encoded in the Remarks field, and usually in the Invoice # prefix as well. KeHE publishes no key to either. This section is what could be established by reading the portal, and it is explicit about where that ends.

Start with the honest part. The K-Solve grid shows exactly the columns its export carries. There is no hidden description field, no expandable row, no tooltip. KeHE does not document its own deduction codes anywhere in the supplier portal, so any list, including this one, is reconstruction rather than reference.

The reference string is usually a code followed by a period or a date. Two patterns recur and are worth recognising because they tell you which period a deduction belongs to:

• AMP<fiscal-year>P<period>, for example AMP2027P05, is an advertising or marketing programme charge. The suffix is a KeHE fiscal period, so P05 is September in fiscal 2027, not May. This is the fiscal calendar showing up somewhere you would not expect it, and it is a good reason to understand the offset.
• SPOIL-<yyyymmdd>, for example SPOIL-20260728, is a spoils charge dated to the day it was raised.

Codes that recur and can be read with reasonable confidence:

And the codes that recur but that nothing in the portal explains: PPF, LDF, NWG, IA, IAA, PL and M52WK. They are listed here because knowing a code is undocumented is more useful than a plausible guess: if you see one, the answer is your KeHE account manager, not a lookup table.

Two further mechanics. The Invoice # prefix is itself a type code, with CS, PF and SWN all appearing. And Remarks is not reliably parseable: it sometimes carries plain prose such as "April 2026 Publication Fees" instead of a code, and the same string is sometimes duplicated into PO #.

The 90-day K-Solve window

The K-Solve grid opens on a rolling 90-day window, and that is the practical limit of your deduction history in the portal. It is undocumented, and it changes how a brand should operate.

This is worth stating plainly because it is easy to discover too late. If you open K-Solve in August, it shows you May onwards. A deduction from March is not on a later page or behind a filter you have not found: the grid simply starts 90 days ago.

The consequence is that KeHE's portal is not your deduction system of record and cannot become one. Annual trade-spend reconciliation, year-over-year deduction analysis, and any dispute older than a quarter all need data you have captured yourself, on a cadence, before it rolls out of the window.

A worked example of what that costs. A spoils charge recurs at roughly $50 a month. Twelve months in, that is $600 and a pattern worth raising. Open K-Solve to build the case and you can see three instances totalling about $150, because the other nine rolled out of the window. The pattern is real, and the evidence for it is not retrievable.

For a brand pulling the export monthly this is a non-issue. For a brand that looks at deductions when the cheque seems wrong, it is a real gap: by the time you notice a pattern, the first few instances of it are gone.

Special Payee and where the money goes

Special Payee names an account the payment was routed to instead of yours, typically a broker or a factor. It appears in both K-Solve and Open AP, and it explains payments that seem to have vanished.

If you use a factoring arrangement, or a broker collects on your behalf, KeHE pays that account rather than you. The deduction still lands against your invoices and still shows in your reports, but the settling cheque went elsewhere. A brand reconciling its own bank statement against K-Solve without accounting for this finds cheques it never received.

The field is a bare account number, and the portal offers no lookup from that number to a name. If you do not recognise it, your finance team or your broker agreement will.

Reconciling a deduction to an invoice

The reconciliation nobody documents: matching a short payment to the specific transactions that made it short. Here is the sequence that works, and the two places it breaks.

Start from the cheque. Take a Check # from K-Solve and pull every row carrying it. Those rows are the batch that cheque settled. Sum Invoice Amt across them, and the total should equal Check Amt on any one of the rows, not the sum of Check Amt, which would multiply it.

A worked example. Four K-Solve rows share one cheque number:

The four sum to $4,145.49, which is the Check Amt shown on all four rows. The reconciliation closes.

It breaks in two places. First, a deduction still in flight is in Open AP, not K-Solve, so a cheque that has not been cut yet cannot be reconciled this way at all. Second, anything older than the 90-day window is not available to match against, so a partial payment referencing an old invoice may have no explanation you can retrieve.

Disputing a deduction

K-Solve is a read-only report. There is no way to dispute a deduction in it.

Its entire control surface is an export button, a sort on each column, and a link out to a third party.

This is worth saying directly because it is the question brands arrive with, and the portal's answer is easy to miss. There is no dispute button, no comment field, no attachment upload, no status you can change. The Status field has exactly two values, one for in progress and one for paid, and neither of them is disputed, denied or reversed. The export cannot tell you whether a deduction was ever challenged.

What KeHE does instead is link out. The K-Solve toolbar carries a link to TrewUp, a third-party deduction-management service, and that is the route KeHE points suppliers at for working deductions. If you are trying to dispute a KeHE deduction, the portal is not where it happens.

The practical consequence for the data is that your dispute history lives outside KeHE entirely, and nothing in the portal will reconcile the two. If recovering deductions matters to your business, the tracking has to be yours.

Forward-looking

One report describes what has not happened yet.

Order Projections

KeHE's forecast of what it expects to order from you, by week and distribution centre. Snapshot, with a Projection Metric parameter offering dollars, units or cases. The only forward-looking report in the portal.

This is the most operationally useful report here for anyone doing demand planning, because it is KeHE telling you what it intends to buy. Compare it to your own forecast and the gap is a conversation worth having before it becomes a service failure.

The metric parameter matters and is easy to forget. The same report returns dollars, units or cases depending on what you picked, and the export does not record which one you chose. Label your pulls.

The measure trap is the important one. Each row carries a weekly leaf value and several rollups: per DC, per brand, and across the whole report, each in a "this week" and an "all weeks" flavour. Only Item_Projection_Week is a leaf. Everything with Total or AllWeeks in the name is a pre-computed rollup stamped on every row, and summing one multiplies it.

A worked example. Sunrise Beverage is projected across seven distribution centres for eighteen weeks. Total_Projection_AllWeeks reads $5,172.92 on every one of the several thousand rows. Summing that column returns tens of millions. Summing Item_Projection_Week returns $5,172.92, which is the actual figure.

One formatting note: dc_name carries the DC as a name and number, and the spacing before the number is not consistent between values. Some read DALLAS (19) and others NOR CAL(33). Parse tolerantly.

The CONNECT BI dashboards

Four visual dashboards live under Connect Analytics, on the same login as the flat reports but built on entirely different technology. They are charts rather than exports, and they cover a fraction of what the flat reports do. They are worth knowing because they are what most people see first.

Analytics dashboard

The flagship. Nine tabs of KPI cards and charts covering sales, category detail, fill rate, purchases, inventory, spoils and financials, with a filter bar offering month-to-date, year-to-date, last twelve months and rolling 13, 26 or 52 weeks.

The summary tab carries the numbers most people quote: sales COGS with a year-on-year comparison, purchases, points of distribution, productive SKU count, and outbound fill rate. A treemap splits COGS by channel.

Two things to understand before trusting a comparison here. The year-on-year arrows compare against the same window a year earlier, which is meaningless for a brand with less than two years of history at KeHE and will read as spectacular growth against a near-zero base. And the underlying data is the same sell-in that the flat reports carry, so a rising line is rising orders, not rising demand.

Everything on this tab traces back to Sales by State and Chains and Stores. If you need the numbers rather than the picture, pull those.

A worked example of the year-on-year trap. Sunrise Cookies launched at KeHE fourteen months ago. The last-twelve-months view compares the most recent twelve months against the twelve before them, of which only two carried any shipments. Current-year COGS of $48,000 against prior-year COGS of $1,400 renders as growth of roughly 3,300%. The arithmetic is correct and the number is useless. A comparison window means something only once two full years sit behind it.

Gap and Void dashboard

The visual companion to Gap Void Sales: status by distribution centre, by channel and by item, a top-ten retailer parent chart, and a map of current, void and gap stores.

The filter panel is the widest in CONNECT BI, covering channel, DC, the full retailer hierarchy, supplier, SKU, brand, POD status, category, status and unit of measure. For exploring whitespace visually it is genuinely good.

The map is the part worth opening it for. Gap and void stores plotted geographically make a pattern visible that a table of six hundred rows does not: a whole metropolitan area with no distribution reads instantly as a territory problem rather than as scattered individual misses.

Where it falls short of the flat report is the money. The dashboard ranks retailer parents by total sales, but closing a gap is a per-store decision and the trailing-52-week figure that sizes it lives at row level in the export. Use the dashboard to find the pattern and the export to build the call list.

The caution is the same one the flat report carries: this dashboard renders empty for a supplier with no current gap or void activity, and an empty dashboard is a legitimate result rather than a broken one.

Order Projection dashboard

Two tabs over the same data as Order Projections: a projection summary and a detail view, with a distribution centre by week matrix and a projected weekly orders line chart.

Filters cover DC, brand, ESN, shipper, projection date range, and the same dollars, units or cases metric toggle the flat report has.

The matrix view is the reason to come here rather than to the export: reading which DC is projected to order what in which week is far easier as a grid than as several thousand rows. Rows are distribution centres, columns are weeks, and the shape of a ramp or a gap is obvious at a glance.

A worked example of what the grid shows that a sum does not. Seven DCs each projected at roughly $600 for a week reads as $4,200 of demand spread evenly. The same $4,200 concentrated in one DC, with the other six at zero, is a very different supply problem, and the total is identical. The matrix distinguishes them; a KPI card does not.

The same weekly-leaf-versus-rollup rule applies to anything you copy out of it: the totals along the edges are the rollups, not additional weeks.

AOM Inventory Gap dashboard

One summary tab covering coverage gaps by account, and currently the only working route to this data, because the flat report's CSV export does not render.

KPI cards show the number of accounts, dollars left to ship and units left to ship, each split between total and inventory-gap. The detail table carries coverage status, distribution centre, account, requested dollars and quantity, quantity on hand, quantity on order, shipped quantity, UPC, brand, description, event start date and buyer.

Coverage status has two values, Inventory Gap and On Track, which is the split the whole dashboard exists to show: accounts KeHE can currently serve against accounts it cannot.

Concepts that decide whether your numbers are right

Seven ideas that are not reports. Each one is a way the portal's data can be technically correct and read wrong.

What an ESN is

An ESN, or Enterprise Supplier Number, is KeHE's identifier for a supplier entity. It is the first parameter on almost every report, and it is the thing that scopes what you can see.

The word "enterprise" is doing real work. A single company can have more than one ESN, and a broker logging in on behalf of several brands sees several. The ESN you pick decides which brands, distribution centres, chains and items appear in every dependent dropdown, which is why picking the wrong one makes a report look empty rather than wrong.

The formatting trap is worth internalising. The portal displays an ESN zero-padded to eight digits. Several exports carry it with the leading zero dropped, at seven. A join between a parameter value and an exported column fails on that difference and returns nothing, which looks like missing data rather than a formatting mismatch.

An ESN also identifies a real business, so it is a value worth treating as confidential in anything you circulate.

A worked example of the join failure. You copy an ESN from the supplier dropdown, where it reads as eight digits beginning with a zero, and use it to filter a K-Solve export whose ESN column carries seven. The filter matches nothing. No error appears, the export is intact, and the obvious conclusion, that there were no deductions in the period, is wrong. Normalise at the point you load the file rather than at the point you query it.

Fiscal months vs calendar months

KeHE's fiscal year starts in May and is named for the calendar year it ends in. Fiscal 2027 runs May 2026 through April 2027. Fiscal period 1 is May, period 2 is June, and so on, month-aligned.

That alone is manageable. What makes it a genuine hazard is that the portal mixes both calendars in the same report picker with nothing signalling which is which except the parameter names. Reports asking for a Fiscal Year and Fiscal Period are on KeHE's calendar. Reports asking for a Calendar Year and Month are on the ordinary one.

A worked example of the failure. You pull Brand Sales Summary for fiscal 2027 period 3 and Full POD Vendor for month 3, intending to compare the same window. Fiscal period 3 is July. Calendar month 3 is March. The two datasets are four months apart, both are internally correct, and nothing in either export says so.

The fiscal calendar also turns up in deduction references, where AMP<fiscal-year>P<period> encodes the period the charge belongs to. A charge tagged P05 is September, not May.

Snapshot vs windowed reports

A windowed report takes a date or period parameter, so you can ask for any past window whenever you like. A snapshot report takes no date parameter at all: it returns the current state, and the only date attached is the day you pulled it.

The consequence is the part nobody states. A snapshot day you did not capture is a day you cannot ever get. There is no parameter that asks the portal what inventory looked like last Tuesday, because the portal does not remember. Miss a pull and that day is permanently blank in your history.

The snapshot reports are Gap Void Sales, Inventory at Risk, Inventory Stock Status, Aged Inventory by Brand, Brand Item Location, AL for ESN Chain Group, Item 360 Recap HD, Open AP Supplier Statement and Order Projections. That is most of the portal.

Two practical implications. If inventory history matters to you, capture on a schedule from the start rather than deciding you need it later. And an empty snapshot export is a legitimate result, not a failure: zero rows of at-risk inventory means there is none today, and that is a real observation worth recording as such.

Inbound vs outbound fill rate

Fill rate is measured twice in this chain and means something different each time. The word is identical, the numbers are unrelated, and confusing them sends you after the wrong problem.

Inbound fill rate is units KeHE received divided by units KeHE ordered from you. It grades your delivery performance and lives in Inbound Fill Rate.

Outbound fill rate is units shipped to stores divided by units the stores ordered from KeHE. It grades KeHE's warehouse availability and lives in Chains and Stores.

A brand can have a perfect inbound number and a poor outbound one. That combination means you delivered everything KeHE asked for and KeHE still could not serve its retailers, which points at forecasting or allocation rather than at you. The reverse combination, poor inbound and adequate outbound, means KeHE absorbed your shortfall out of existing stock, and that buffer will not last.

Both are ratios of orders to shipments. Neither is a measure of what shoppers bought.

Sell-in vs sell-through

Sell-in is what a retailer ordered from a distributor. Sell-through is what a shopper bought at the register. KeHE reports the first and cannot see the second, and every number in this portal sits on the wrong side of that line for demand analysis.

The reason is structural rather than a gap KeHE could close. KeHE's commercial relationship ends when it delivers to a store. The register belongs to the retailer, and scan data is the retailer's to share or sell. A distributor is not in that transaction.

What this means in practice is that KeHE data answers "how much did we ship" extremely well and "is the product selling" not at all. A perfectly healthy brand shows a down month at KeHE because retailers happened to be overstocked. A brand in real trouble shows a flat month because retailers have not yet cut their orders to match falling velocity. Distributor data lags the shelf, and it lags it by however much inventory sits in between.

For actual sell-through you need a different source: retailer POS, or a syndicated panel that models it. Reading KeHE and UNFI movement through a syndicated panel has its own set of quirks, and our guide to reading KeHE and UNFI movement data in SPINS covers those rather than repeating this argument.

A worked example of the lag. Sunrise Market's stores hold about three weeks of Sunrise Cookies inventory. Shopper demand falls 20% in week one. Stores keep ordering at the old rate through weeks one and two, because their shelves still look normal, then cut sharply in week three when the backroom fills. KeHE's sell-in shows a flat fortnight and then a cliff. The shelf saw a gradual 20% decline; the distributor data showed nothing, then everything. Neither is wrong, and only one of them is demand.

The general distinction has a fuller treatment at consumption vs shipment data.

One DC, five spellings

A KeHE distribution centre is written five different ways across the portal. Nothing normalises them for you, and a join on distribution centre across two reports fails silently unless you do it yourself.

All five refer to real, identical warehouses. The number in the dropdown and the number in DCNumber are the same number, one zero-padded and one not.

There is a further wrinkle inside a single report: Order Projections uses the dropdown form but does not space it consistently, so DALLAS (19) and NOR CAL(33) appear in the same column.

If you are building anything that spans two KeHE reports, a distribution centre lookup table is not optional, and it is the first thing to build.

A worked example of the failure. You want on-hand units beside projected orders per DC, so you join Inventory Stock Status, whose DC reads Bloomington, IN, against Order Projections, whose dc_name reads BLOOMINGTON (16). Exact matching returns nothing. Case folding does not help. Stripping the parenthesised number does not help either, because one form carries a state and the other does not. What works is a lookup keyed on KeHE's DC number, which means parsing the number out of one column and zero-padding it to match the other.

Rollup columns and the SUM trap

Several KeHE reports pre-compute totals at each level of a hierarchy and stamp them onto every single leaf row. Summing one of those columns multiplies the total by the number of rows underneath it, and the result looks plausible.

This is the most common way to get a badly wrong number out of this portal, because nothing about the column name warns you. TotalQuantityOnHand sounds like a total you would sum.

The tell is a prefix. Columns beginning Total, Brand, Dc, RetailerParent or RetailerArea are almost always rollups. The leaf is the version with no prefix at all: QuantityOnHand, Shipped, QtyShipped, Item_Projection_Week.

A worked example of the magnitude. In one Order Projections pull, Total_Projection_AllWeeks reads $5,172.92 and there are 5,250 rows. Summing the column returns just over $27 million against a real figure of about $5,000, an overstatement of five thousand times. It is obviously wrong at that scale; the dangerous case is a report with forty rows, where the same mistake returns a number that merely looks like a good month.

The reports that carry rollup families are Inventory Stock Status, Chains and Stores, Sales by State, Aged Inventory by Brand and Order Projections. K-Solve's Check Amt and Open AP's TotalBalance behave the same way without the naming convention.

Getting the data out

Three practical notes on moving from the portal to something you can work with.

Exporting a report

Every flat report exports once it has rendered. The sequence is always the same: pick the report, fill the parameter panel, click View Report, wait for the body to render, then export.

The order matters. Export acts on a rendered report, so exporting before the body appears produces an error rather than a file. On a wide report with a large account, rendering can take a while, and the parameter panel staying on screen is not a sign that anything is wrong.

Two format notes. The flat reports export CSV. K-Solve, on the legacy portal, exports Excel. And the CSV carries the report's header row as its first line, which for the reports that flatten their parameter banner into columns means the header describes banner columns as though they were data.

What the export does not carry

An export is not a complete record of what you pulled, and the gaps are the things you most need three months later.

The parameters are not in the file, with one exception. Nothing in a Gap Void Sales export records which retailer parent you filtered to, and nothing in an Order Projections export records whether you chose dollars, units or cases. Full POD Vendor is the exception, and only because it flattens its whole banner into columns.

The period is often not in the file either. Snapshot reports have no date column at all, so the day you pulled it is knowledge that lives outside the export.

Units are ambiguous more often than they should be: several quantity columns do not say whether they hold eaches or cases, and the answer is not the same from one report to the next.

The practical answer is a naming convention. Put the report, the period or pull date, and the metric into the filename at the moment you export, because none of it is recoverable from the file afterwards.

Where Scout fits

Scout is a demand-side analytics layer. It does not give you access to KeHE CONNECT Supplier, it is not an EDI gateway, and it is not part of your supply chain. Access to the portal comes from KeHE.

What Scout does with this data is join it to everything else. A brand's KeHE sell-in sits alongside its UNFI shipments, its direct retailer POS and its syndicated panel data in one place, on one set of column names, so that the distribution question and the velocity question can be asked together rather than in five browser tabs.

The reference tables throughout this guide are generated from Scout's own template catalog, which is why they carry the portal's column names and their meanings side by side. That catalog is what a KeHE feed lands in.

If you already pull these reports by hand every week, the value is mostly the scheduling and the history: the snapshot reports in particular are only as good as the days you remembered to capture, and a day you did not pull is a day you cannot get back.