Stockkeeping Unit Table in Business Central: API & Schema

The Stockkeeping Unit table (table 5700) in Microsoft Dynamics 365 Business Central stores location- and variant-specific planning parameters for an item. Each row represents one combination of Item, Location, and Variant, and acts as a per-warehouse override of the planning, vendor, and replenishment settings on the underlying Item card. Stockkeeping Units are how Business Central models the reality that the same product can have a different reorder point in Auckland than it does in Wellington, or a different preferred vendor at a transit depot than at a retail store.

Microsoft API status

The Stockkeeping Unit table is not exposed in the Business Central REST API v2.0. There is no standard stockkeepingUnits endpoint. Historically the workaround was to publish Page 5701 (Stockkeeping Unit Card) as an OData web service, but Microsoft is deprecating the practice of exposing standard pages as APIs, so that path is no longer recommended for new integrations. The remaining options are to write a custom API page in AL and deploy it as an extension to every tenant, or to use Skuno BI, which exposes the table as a full OData v4 endpoint (https://<tenant>.skuno.app/api/v2.0/odata/bc/Stockkeeping_Unit_5700) without per-environment AL development.

That gap is bigger than it looks. Replenishment automation and planner-facing dashboards lean directly on SKU parameters, and most BC integrations work around the missing endpoint by pulling Items, joining against Inventory by Location, and re-deriving the SKU rules at runtime. The re-derivation is brittle: every time a planner edits an SKU directly in BC, the integration’s view of the world diverges from what planning actually uses.

When to use the Stockkeeping Unit table

Use Stockkeeping Unit when you need location- or variant-specific planning behaviour: a different reorder point, vendor, or lead time per location, transfer routing between warehouses, or per-location costing parameters. Use the Item table directly when those parameters are uniform across your operation. Use Item Variant alone when you have product variants (colour, size) that share planning settings across locations.

A useful rule of thumb: if your inventory planner ever says “we order more of X for the Auckland warehouse than for Wellington,” you should be using SKUs.

Query examples

The underlying schema is the same in every example below. What changes between them is the naming convention (AL field names vs. SQL bracketed names vs. OData-safe names), the filter syntax, and how much of the table you can actually see from the endpoint.

AL

var
    SKU: Record "Stockkeeping Unit";
begin
    SKU.SetRange("Location Code", 'BLUE');
    SKU.SetFilter("Reorder Point", '>0');
    if SKU.FindSet() then
        repeat
            // process each SKU
        until SKU.Next() = 0;
end;

SQL (on-prem only)

SELECT TOP 100
    [Location Code], [Item No_], [Variant Code],
    [Reorder Point], [Reorder Quantity], [Vendor No_]
FROM [CRONUS$Stockkeeping Unit$00000000-0000-0000-0000-000000000000]
WHERE [Location Code] = 'BLUE'
  AND [Reorder Point] > 0;

Direct SQL access is only supported on Business Central on-prem deployments; SaaS environments lock down the database.

Custom API page (AL)

page 50100 "Stockkeeping Unit API"
{
    PageType = API;
    SourceTable = "Stockkeeping Unit";
    APIPublisher = 'contoso';
    APIGroup = 'inventory';
    APIVersion = 'v1.0';
    EntityName = 'stockkeepingUnit';
    EntitySetName = 'stockkeepingUnits';
    DelayedInsert = true;
    ODataKeyFields = SystemId;

    layout
    {
        area(content)
        {
            repeater(Group)
            {
                field(itemNo; Rec."Item No.") { }
                field(variantCode; Rec."Variant Code") { }
                field(locationCode; Rec."Location Code") { }
                field(reorderPoint; Rec."Reorder Point") { }
                field(reorderQuantity; Rec."Reorder Quantity") { }
                field(vendorNo; Rec."Vendor No.") { }
            }
        }
    }
}

A custom API page is now the only Microsoft-supported way to expose the SKU table over HTTP from a SaaS tenant. It must be deployed as part of an AL extension to each environment that needs it.

Skuno BI (OData v4)

Skuno BI exposes Stockkeeping Unit as a full OData v4 endpoint. The path is tenant-scoped and table-numbered, so the table is addressable without any per-environment AL deployment.

The response is a superset of the base schema documented above: in addition to every base-table field, Skuno BI surfaces FlowFields evaluated server-side and any columns added by table extensions installed on the tenant. Microsoft’s Manufacturing module, for example, adds Production_BOM_No, Routing_No, Qty_on_Prod_Order, and the planned / firm-planned / released order receipt quantities; Warehouse, Service, and third-party apps add their own fields on the same record. The $metadata document at the endpoint root reflects whichever extensions are actually deployed on that tenant. If a field appears in your response that isn’t in the schema table above, it almost always came from a table extension rather than from the base SKU table.

GET https://mycompany.skuno.app/api/v2.0/odata/bc/Stockkeeping_Unit_5700
    ?$filter=Location_Code eq 'BLUE' and Reorder_Point gt 0
    &$select=Item_No,Variant_Code,Location_Code,Reorder_Point,Reorder_Quantity,Vendor_No
    &$top=100

A trimmed response:

{
	"@odata.context": "https://mycompany.skuno.app/api/v2.0/odata/bc/$metadata#Stockkeeping_Unit_5700",
	"value": [
		{
			"Item_No": "1000",
			"Variant_Code": "GREEN / L",
			"Location_Code": "",
			"Replenishment_System": "Purchase_0",
			"Reordering_Policy": "0",
			"Reorder_Point": "0",
			"Reorder_Quantity": "0",
			"Maximum_Inventory": "0",
			"Safety_Stock_Quantity": "0",
			"Lead_Time_Calculation": "",
			"Vendor_No": "",
			"Assembly_Policy": "Assemble_to_Stock_0",
			"Manufacturing_Policy": "Make_to_Stock_0",
			"Flushing_Method": "Manual_0",
			"Inventory": "0",
			"Qty_on_Purch_Order": "0",
			"Qty_on_Sales_Order": "0",
			"Qty_in_Transit": "0",
			"Last_Date_Modified": "2026-04-18",
			"Use_Cross_Docking": 1,
			"systemId": "{520273F8-E43A-F111-BEC2-6045BDC3ECAB}",
			"SystemCreatedAt": "2026-04-18T05:10:56.417Z",
			"SystemModifiedAt": "2026-04-18T05:10:56.417Z"
		}
	]
}

Standard OData query options apply: $filter, $select, $top, $skip, $orderby, and $count.

Gotchas

Field-number order vs. primary-key order. The fields are declared on the table in the order Item No. (1), Variant Code (2), Location Code (3). The clustered primary key, however, is Location Code, Item No., Variant Code (Key1). Integrations that build keys from fields[0..2] will get the order wrong; use the key definition, not the declaration order.

At least one of Location Code or Variant Code must be set. The OnInsert and OnRename triggers reject any SKU where both Location Code and Variant Code are blank. That’s just an Item, not an SKU. The error message refers to Text000 in the AL source.

Composite key, not a surrogate. There is no SKU No. integer column. Every join from another table needs all three columns, and a blank Variant Code counts as a distinct value, not “any variant.”

SKUs are optional and the absence of one matters. Business Central uses SKU planning parameters only when a row exists for the exact Item/Location/Variant combination being planned. If a planner deletes an SKU row, planning silently falls back to Item-level parameters, which is rarely what was intended. The OnInsert trigger calls PlanningAssignment.AssignOne to keep the requisition worksheet aware of new SKUs.

Quantity-on-hand is a FlowField, not a column. Inventory (field 68) is computed on demand from Item Ledger Entry; it doesn’t exist on the SKU row. SQL and OData consumers that select it without a CalcFields (or equivalent OData expansion) get zero. For warehouse-level on-hand, prefer Item Ledger Entry filtered by Item No., Location Code, and Variant Code directly.

Replenishment System change doesn’t backfill. Changing an SKU from Purchase to Transfer doesn’t reroute existing open purchase orders. The change only affects requisition-worksheet runs after the edit. It also recomputes Transfer-Level Code (field 5400) and rejects circular transfer graphs.

No base UoM override. The SKU table has no Unit of Measure Code field. Base UoM lives on the Item and applies across all SKUs. Field 7307 (Put-away Unit of Measure Code) is warehouse-only and doesn’t change costing or ledger units.

Transfer routes are required, not optional. Setting Transfer-from Code triggers CheckTransferRoute, which errors if no Transfer Route record exists between the two locations. SKUs cannot silently route around missing routes.

Published-page OData is being deprecated. Publishing Page 5701 (or any standard page) as an OData web service was the historical workaround for the missing API. Microsoft is winding that pattern down, and the page-based property names were always unstable, as they’re derived from the AL caption and can break when the page is edited. New integrations should use a custom API page in AL or a sync-based product like Skuno BI rather than starting on page-based OData today.

How Skuno BI exposes Stockkeeping Unit

Skuno BI surfaces the full Stockkeeping Unit table, including FlowFields and any columns added by Manufacturing, Warehouse, or other Microsoft (and third-party) table extensions installed on the tenant, as a queryable OData v4 endpoint at https://<tenant>.skuno.app/api/v2.0/odata/bc/Stockkeeping_Unit_5700. Item, Location, Item Ledger Entry, and the rest of the planning-relevant tables are exposed on the same convention, with the BC table number suffixed onto the resource name. Standard OData query options ($filter, $select, $top, $orderby, $count) work against any column, including FlowFields like Inventory and Qty_on_Purch_Order, which are evaluated server-side so consumers don’t have to mimic CalcFields. The endpoint is backed by an analytical column store, so filter performance doesn’t depend on the underlying BC SQL keys.

SKU data drives planning across every location in your business, and reading it out of your own database shouldn’t require an AL extension deployed to every tenant just to get an API page.

See how Skuno BI surfaces Business Central data →