Blocked items and customers in Business Central

Every operational dataset in Business Central — items, customers, vendors, resources — carries a Blocked field. The intent is simple: stop transactions against the record without deleting it. The execution is more nuanced than it first looks, and getting the block design wrong is one of the more common causes of "the system is preventing us from doing our job" support tickets.

The three block levels on items. The Item card has a Blocked boolean, but most teams discover only after a few months that there are actually three distinct block fields:

• Blocked — stops everything: purchases, sales, transfers, production, journals. The item effectively vanishes from operations.
• Sales blocked — stops outbound (sales orders, sales invoices, transfers to other locations on sales).
• Purchasing blocked — stops inbound (purchase orders, purchase invoices).

The split exists because real-world reasons to block are usually directional. A discontinued item shouldn't be purchased but the remaining stock still needs to be sold. A recalled item needs to stop selling but vendor returns and adjustments must continue.

Customer blocks. Customers have three values in the Blocked field:

• (blank) — fully active.
• Ship — new sales orders can be entered, but no shipping or invoicing.
• Invoice — shipping is allowed, but no invoicing.
• All — no new orders, no shipping, no invoicing.

Ship is the credit-hold value most finance teams use — sales reps can still enter quotes and orders so commercial conversation continues, but warehouse won't release goods.

Vendor blocks. Vendors mirror customers:

• (blank) — active.
• Payment — invoices post but payments are blocked.
• All — no new orders, no invoices, no payments.

Payment is the most common — typically used while an invoice dispute is open: you want to keep posting expense recognition but withhold cash.

Resources, locations, accounts. Resources have a single Blocked boolean. G/L accounts have Blocked and Direct posting. Locations have Use as in-transit. Item charges have Blocked. The pattern is consistent: a field whose presence is detected by validation routines on document headers and lines.

Where the check fires. Blocks are validated on the document line at the moment the user enters the item or customer number, and again on posting. A blocked item entered before the block was applied stays on the line — Business Central does not retroactively scan open orders. This means applying a block does not stop existing pipeline, only new entries. Teams expecting an instant freeze are sometimes surprised.

Credit-limit blocks vs hard blocks. Customer Blocked = Ship and a credit limit warning are different mechanisms:

• Credit limit — warns or hard-stops based on Credit Limit (LCY) vs Balance + outstanding orders. Configurable per company via Credit Warnings on Sales & Receivables Setup.
• Blocked — explicit operational block, regardless of balance.

Mature credit-control practice uses credit limits for routine over-limit situations and Blocked for unusual ones (disputes, suspected fraud, terminated relationships).

Audit trail. Changes to block fields are captured by Change Log if enabled on the table. For SOX-relevant environments, enable change log on Customer, Vendor, and Item tables and audit the trail monthly.

Bulk operations. Blocking 200 items at once is common during a discontinuation campaign. Options:

• Edit in Excel via the Excel add-in.
• Configuration Package import (less common for this use).
• Edit list within the item list page itself (Ctrl+Alt+F7).

There's no native scheduled block — automation requires a small AL extension or a Power Automate flow that updates records via the BC API.

Permissions. The right to set Blocked on a customer or vendor is usually restricted via permission sets — credit controllers can block customers; AP managers can block vendors. Don't leave these permissions on every accountant; a wrongful block is operationally expensive.

Common pitfalls.

• Blocking on the wrong axis. Setting Blocked = All on a customer when only credit-hold is intended; sales loses pipeline visibility.
• Forgetting open documents. Applying a block doesn't clear pending shipments — they need separate handling.
• No release process. Blocks accumulate; nobody owns un-blocking. Build a periodic review cadence.
• No reason captured. The block field doesn't have a built-in reason. Most teams add a Reason for Block field via extension or use Description 2 informally.

A clean block strategy treats these fields as a controlled lifecycle, not an emergency switch.