EDI 846 Inventory Inquiry Advice: BIA, LIN and QTY Segments
Sep 2, 2026
Sep 2, 2026
Convert a purchase order to Excel, CSV, or JSON
Submit your purchase orders
Drop documents here, or click to file
Up to 50 files per batch
Uploading...
An EDI 846 is the X12 inventory inquiry or advice: a supplier telling a trading partner what stock exists and where. It carries no order and no commitment. The item sits in a LIN segment, the numbers sit in a QTY loop that can repeat up to 99 times per item, and the qualifier in QTY01 is what decides whether you are looking at stock on hand, stock available for sale, stock on hold or a minimum stock level. Reading the first QTY and calling it availability is the mistake that causes oversells.
Last updated September 2026
The 846 is the quietest document in a trading relationship and one of the few that changes what you buy. A purchase order is a decision already made. An inventory advice is the input to the decision, and it arrives daily, or hourly, from suppliers who would rather you ordered what they can actually ship. When it is read correctly it prevents backorders. When it is read carelessly it manufactures them, because the document is generous with quantity fields and silent about which one you should trust.
This is a reference for the segments, elements and code lists in an 846, written for the buying side: the people loading these files into a planning sheet or a reorder routine rather than the people generating them.
Three situations produce an 846. A supplier publishes stock levels so their distributors and retailers can plan replenishment. A distributor reports back what they are holding of a manufacturer product, which is how consignment and vendor managed inventory programs get their numbers. Or a buyer sends an inquiry asking what is available, and the supplier answers with an 846 of their own.
Because the same transaction set covers all three, the document does not tell you its role in the segment structure. It tells you in one two character code in the header, which is covered below and is the first thing to read.
The heading identifies the report and the parties. The detail is one LIN loop per item. There is no order header, no dollar total and no acknowledgment expectation.
| Segment | Section | Requirement | What it carries |
|---|---|---|---|
| ST | Heading | Mandatory | Transaction set identifier 846 and the control number |
| BIA | Heading | Mandatory, max 1 | Purpose code, report type code, reference identification, date and time |
| CUR | Heading | Optional | Currency, present only when the file carries pricing |
| DTM | Heading | Optional | Dates the report relates to, such as the as of date |
| REF | Heading | Optional | Contract, agreement or catalog references |
| N1 loop | Heading | Optional, max 5 | Parties: whose inventory, at whose location, reported to whom |
| LIN loop | Detail | Mandatory, repeats | One per item. Everything else in the detail hangs below it |
| PID | Detail | Optional, max 200 | Product description in free text |
| DTM | Detail | Optional | Item level dates such as expected availability |
| CTP | Detail | Optional | Pricing, when the advice doubles as a price file |
| SDQ | Detail | Optional | Destination and quantity detail: the same item split across locations |
| QTY loop | Detail | Optional, max 99 | The quantities themselves, one loop per qualifier |
| SLN loop | Detail | Optional, max 1000 | Subline items, for kits and packs |
| CTT | Summary | Optional | Transaction totals |
| SE | Summary | Mandatory | Trailer with the segment count |
Two things in that table matter more than they look. The QTY loop is optional, so an 846 line with no quantity at all is structurally valid. And CTT is optional, which means you cannot rely on a line count to prove your parser read every item. On an EDI 855 acknowledgment or an EDI 850 purchase order you usually have CTT01 to check against. Here you often do not, so count LIN segments yourself and compare against the previous file from the same partner.
Four of the six BIA elements are mandatory, which is unusual and helpful. The two that decide everything are BIA01 and BIA02.
| Element | Number | Name | Requirement | Note |
|---|---|---|---|---|
| BIA01 | 353 | Transaction Set Purpose Code | Mandatory | 00 Original, 01 Cancellation, 05 Replace, 08 Status, 22 Information Copy |
| BIA02 | 755 | Report Type Code | Mandatory | Whose inventory this is and from whose point of view |
| BIA03 | 127 | Reference Identification | Mandatory | The report number, up to 30 characters. Your idempotency key |
| BIA04 | 373 | Date | Mandatory | CCYYMMDD. The as of date, not the transmission date |
| BIA05 | 337 | Time | Optional | Matters when a partner sends several files a day |
| BIA06 | 306 | Action Code | Optional | Rarely populated on inventory files |
Element 755 is the report type code, and it is the field that turns an anonymous list of parts and numbers into a statement about a specific party. The inventory values look similar and mean different things.
| Code | Meaning |
|---|---|
| SI | Seller Inventory Report |
| MM | Manufacturer Inventory Report |
| DD | Distributor Inventory Report |
| LC | Location Inventory Report |
| MB | Manufacturer/Distributor Inventory Report |
| MC | Manufacturer/Customer Inventory Report |
| DC | Distributor/Customer Inventory Report |
| DM | Distributor/Manufacturer Inventory Report |
| CD | Customer/Distributor Inventory Report |
| CM | Customer/Manufacturer Inventory Report |
| AD | Agent/Distributor Inventory Report |
| AA | Agent Inventory Report |
| PT | Inter-Plant Inventory Report |
The paired codes read as source and subject. A DM report is a distributor reporting to a manufacturer, and an MB report is a manufacturer reporting to a distributor. The quantities in those two files describe stock in different buildings owned by different companies. Loading both into one table keyed on part number, which is what a generic loader does, produces a stock figure that is the sum of two separate warehouses and belongs to neither. Carry BIA02 through to every row you write. It costs one column.
Transaction set purpose codes on an 846 are usually 00 Original or 05 Replace, and the difference is the difference between adding and overwriting.
Most partners send a full snapshot every cycle: every item they stock, with current numbers, labelled 00. A few send only what changed. A few send 05 Replace and expect you to clear the prior file for that partner first. Nothing in the file distinguishes a full snapshot labelled 00 from a partial one labelled 00, so this has to be established with the partner and written down, not inferred. The failure mode is quiet in the direction that costs money: if you treat a partial file as a full snapshot, every item not mentioned this cycle silently drops to zero and your reorder routine buys stock you already have coverage for.
Watch for 01 Cancellation and 22 Information Copy as well. A 22 is a courtesy copy of a report sent to someone else, and acting on it as though it were addressed to you is a category error.
LIN identifies the item. LIN01 is an optional assigned identification, and after that the segment is a series of qualifier and value pairs, up to twelve of them, exactly like the product identification on an invoice line.
| Element | Number | Name | Requirement |
|---|---|---|---|
| LIN01 | 350 | Assigned Identification | Optional |
| LIN02 | 235 | Product/Service ID Qualifier | Mandatory |
| LIN03 | 234 | Product/Service ID | Mandatory |
| LIN04 | 235 | Product/Service ID Qualifier | Conditional |
| LIN05 | 234 | Product/Service ID | Conditional |
| LIN06 to LIN31 | 235 and 234 | Further qualifier and ID pairs | Conditional |
Read the qualifier, then take the value. Common qualifiers are BP for the buyer part number, VP for the vendor part number, UP for a UPC and EN for an EAN. Taking LIN03 blindly means you get whichever identifier the supplier decided to put first, and suppliers reorder these between file versions without telling anybody. A loader that hunts for the BP pair keeps working when they do.
Here is the heart of the document. Quantities on an 846 live in QTY segments inside a loop that repeats up to 99 times per item. QTY01 is element 673, the quantity qualifier, and it is what the number means.
| QTY01 | Meaning | What it is good for |
|---|---|---|
| 33 | Quantity Available for Sale | The number you can actually order against |
| 17 | Quantity on Hand | Physical stock, including units you cannot have |
| QH | Quantity on Hold | Cannot ship at present for any reason, excluding damaged units |
| 20 | Unusable Quantity | Damaged or otherwise unsellable |
| 72 | Minimum Stock Level | A threshold, not a balance. Never a quantity you can buy |
| 99 | Quantity Used | Consumption in the period, used in vendor managed programs |
| QA | Quantity Approved | Allowed by the party processing a claim |
| QP | Quantity by Position | Positional breakdown, rarely useful on its own |
This is the misreading that costs real money, and it is easy to make because both numbers are plausible and one of them is bigger.
Qualifier 17 is quantity on hand: what is physically in the building. It includes stock on hold, stock allocated to other customers orders, damaged units awaiting disposition and product in quarantine. Qualifier 33 is quantity available for sale, which is what remains after all of that. A supplier who sends both is being helpful. A reorder routine that reads the first QTY in the loop, or that reads 17 because the label sounds authoritative, will order against a number that includes stock nobody can ship. The order goes in, the acknowledgment comes back with lines backordered, and everyone blames the supplier for an oversell that the file predicted correctly.
The same shape shows up across the family: a value that reads like a success or a supply and is not. It is why a clean 997 functional acknowledgment does not mean an order was accepted, and why an acknowledgment status code on an 855 has to be read per line rather than per document.
Two practical rules. Prefer 33 when it is present and fall back to 17 minus QH minus 20 when it is not, documenting the fallback so the difference is visible later. And never let 72 into an availability column. It is a reorder threshold, and treating it as stock produces a small, constant, invisible error.
QTY02 is the quantity itself, a plain decimal. QTY03 is C001, a composite unit of measure rather than a simple two character code, and it is optional. So an 846 can legitimately hand you a number with no unit attached.
That is different from an invoice, where IT103 is a plain unit code sitting next to the quantity, and it catches people who move from parsing an EDI 810 invoice to parsing an 846. When the unit is missing, the assumption is the partner default from the trading agreement, which usually means each. Assume it, but record the assumption in a column so a case pack against each error is findable rather than mysterious.
SDQ carries destination and quantity detail, and it is how one item reports different stock in different warehouses. The structure is a unit of measure, an identification code qualifier, then repeating pairs of location code and quantity: SDQ03 with SDQ04, then SDQ05 with SDQ06, and onward through SDQ21 and SDQ22.
The rule in the standard is that if either half of a pair is present the other is required, so the pairs never come apart. What does come apart is a parser that reads QTY and ignores SDQ. When a supplier reports by location, the per location numbers are in SDQ and the QTY loop may carry only a rolled up total or nothing at all. A location aware buyer looking at a QTY only extract sees a national number and orders from the wrong distribution center.
Some partners use the 846 as a combined availability and price file, which is where CTP appears. CTP02 is the price identifier code, CTP03 is the unit price using element 212, CTP04 is the quantity the price applies to and CTP05 is again a composite unit of measure. CTP06 and CTP07 carry a multiplier when the price is expressed as a factor rather than an amount.
Note that CTP03 uses element 212, a real decimal with the point written out, which is the same element as IT104 on an invoice. It is not one of the implied decimal amount elements, so no division is needed. Mixing that rule up in either direction is a hundredfold error that still looks like money.
The file below is a short two item advice. Read it in the order the segments make sense, not top to bottom.
ST*846*0001~
BIA*00*SI*INV-20260902-01*20260902*0600~
N1*SU*NORTHFIELD SUPPLY CO*92*NSC001~
LIN*1*BP*44-8820*VP*NS44820~
QTY*17*820~
QTY*QH*140~
QTY*33*680~
LIN*2*BP*44-8825*VP*NS44825~
QTY*17*45~
QTY*72*100~
CTT*2~
SE*12*0001~
BIA02 first. It is SI, a seller inventory report, so these numbers describe the supplier stock and not yours. BIA01 is 00, an original, and BIA03 gives you a report reference to deduplicate on if the same file arrives twice.
Line 1 is the instructive one. On hand is 820, on hold is 140, available for sale is 680. Only 680 can be ordered. A routine reading the first QTY takes 820 and overstates availability by 140 units, and the arithmetic does not quite close either, because 820 minus 140 is 680 only if nothing is damaged. Trust the supplied 33 rather than your own subtraction.
Line 2 has no 33 at all. On hand is 45 and the other value is a minimum stock level of 100, not a quantity you can buy. A parser that takes the largest number, or the last one, records 100 available for an item that has 45 in the building and is already below its reorder point. When a line looks like this repeatedly, the practical response is not a better parser, it is a second source, and finding one quickly is its own exercise in sourcing new vendors before the shortage reaches your own customers.
The flattening that works is one row per item and quantity qualifier, with the header repeated. Pivoting the qualifiers into columns comes second, once you know which qualifiers a partner actually sends.
| Column | Source |
|---|---|
| Report reference | BIA03 |
| As of date and time | BIA04 and BIA05 |
| Purpose | BIA01 |
| Report type | BIA02 |
| Party | N1 loop |
| Buyer part | LIN pair with qualifier BP |
| Vendor part | LIN pair with qualifier VP |
| Description | PID05 |
| Quantity qualifier | QTY01 |
| Quantity | QTY02 |
| Unit | QTY03 composite, blank when absent |
| Location | SDQ03 and its repeating pairs |
| Price | CTP03 when present |
| Available date | DTM in the LIN loop |
Keep QTY01 as a visible column rather than resolving it during the load. The moment a qualifier is collapsed into a single availability figure you lose the ability to explain a discrepancy to the supplier, and explaining it is most of the work.
An 852 is product activity data: what sold, what moved, what was received over a period. An 846 is a position at a point in time. They are often confused because both carry part numbers and quantities and both feed replenishment, but they answer different questions. If you need to know whether to reorder today, that is an 846. If you need to know how fast the item is turning, that is an 852. Programs that only ingest one of the two tend to reorder on stale velocity assumptions or on a position with no trend behind it.
An inventory advice is upstream of everything else. It informs the order you send as an 850, which the supplier answers with an 855, amends with an 860 if quantities change, and eventually bills with an 810. When availability was misread at the start, the correction happens at the end, as a backordered acknowledgment line or a short shipment, at which point it costs a phone call rather than a column.
If you are working through the surrounding transaction sets, the EDI 850 to Excel converter covers the purchase order itself, the EDI 855 to Excel converter covers the acknowledgment and all 26 ACK01 status codes, the EDI 810 to Excel converter covers the invoice that closes the loop, and the EDI to Excel converter guide covers the envelope and delimiter rules that apply to every file including this one.
For the availability traffic that never arrives as EDI at all, which for most buying desks is the larger half, suppliers send stock lists and confirmations as PDFs and spreadsheets attached to email. Our purchase order PDF to Excel converter turns those documents into the same columns your EDI feed already writes, so both channels end up in one sheet instead of two processes.
Stop retyping purchase orders
Upload a PDF, scan, or photo of any PO and get clean Excel, CSV, or JSON line items in seconds.
Try it free25 pages free. No credit card required.