The planning agent BC's worksheets were missing

Pre-launch — join the waitlist for founding pricing.

Last reviewed: 2026-05-21

Business Central’s Planning Worksheet and Requisition Worksheet use the same engine and do the same job — net demand against supply, then surface action messages a planner reviews and accepts line by line. [1] The work the worksheets don’t do is the deciding work: which of those action messages to act on this week, which to defer, which transfer order would close a multi-warehouse imbalance without depleting the source, how the 17 planning parameters per item per location should adjust as your sales mix shifts. That judgment stays with your planner.

Isovel is the agent that does the deciding — and writes the resulting draft purchase orders and transfer orders back into BC’s Requisition Worksheet for your planner to approve. Every write-back is approval-gated by default, idempotent (re-runs never duplicate writes), reversible within a 24-hour rollback window, and audit-logged with the agent’s rationale string on every line.

17

planning parameters per item per location your BC planner maintains by hand — verbatim from a 5,602-point Microsoft Super User.

community.dynamics.com — BC Super User planning-parameter enumeration [2]

38%

excess inventory at SMBs — Netstock 2024 Inventory Management Benchmark Report (n=2,400).

Netstock 2024 Inventory Management Benchmark Report [3]

15–25%

of inventory value per year is what carrying that excess costs you (storage, capital, obsolescence, insurance).

APICS Puget Sound Chapter — Cost of Carrying Inventory [4]

Phase 1   Pre-launch waitlist. One-click install — listing coming to Microsoft AppSource. $999/month or $10,000/year (12-month commitment, ~17% discount). Fair-use limits apply for high-volume tenants.

What Business Central’s planning worksheets do today

The Planning Worksheet and Requisition Worksheet share a single planning engine and perform the same calculation — independent BC training site UseDynamics titles their canonical tutorial “The Requisition Worksheet and Planning Worksheet uses the same engine and performs the same job.” [1] Microsoft’s own training module names “differences between the requisition worksheet and the planning worksheet” as a discrete learning objective, which acknowledges the split is a comprehension blocker for operators. [5]

What the engine does, in Microsoft’s own words: “Anticipated and actual customer demand, and inventory reordering parameters, drive the planning system. Running the planning calculation results in suggestions for specific actions (Action Messages) to take for possible replenishment from vendors, transfers between warehouses, or production.” [6] Four action verbs come out the other side — Purchase, Produce, Transfer, Assembly — and the planner reviews, accepts, and carries them out from a worksheet line. [7]

That is the surface Isovel sits on top of. Microsoft itself defines BC’s planning output as suggestions. The deciding work — which suggestions to act on, which to defer, which transfer would unblock another warehouse, when the underlying parameter ought to change — is what BC’s planning surfaces hand off to the planner, and what Isovel does.

The 17 parameters per item per location

A 5,602-point Microsoft Super User answered a 2026 BC planning-worksheet thread by enumerating the parameter surface a planner maintains for the worksheet to produce trustworthy output. The list, verbatim:

“The following planning parameters exist on the item or SKU card: Dampener Period, Dampener Quantity, Reordering Policy, Reorder Point, Maximum Inventory, Overflow Level, Time Bucket, Lot Accumulation Period, Rescheduling Period, Reorder Quantity, Safety Lead Time, Safety Stock Quantity, Assembly Policy, Manufacturing Policy. The following order modifiers exist on the item or SKU card: Minimum Order Quantity, Maximum Order Quantity, Order Multiple.” [2]

Fourteen planning parameters plus three order modifiers — 17 fields per item per location, because BC’s Stockkeeping Unit table is the per-location override layer. [8] A 1,000-SKU distributor with three warehouses runs 51,000 cells of human judgement. The same Super User and most of the community posts that follow the same thread converge on the same shape of frustration: “Demand forecasts often fail to properly feed into planning worksheets,” and “Native MRP doesn’t easily display inventory across locations, so planners might unnecessarily manufacture items that are available elsewhere” are Insight Works’ own framing of the gap their Enhanced Planning Pack monetizes. [9] The page-1 independent BC practitioner result on the planning-worksheet keyword closes the loop on what planners actually do when the worksheet output stops making sense: “If all else fails, and you struggle to visualise why Business Central is suggesting a line, do a graphical representation in Excel!” [10]

Five of six BC distributors we’ve talked to in 2026 keep a parallel Excel and a Power BI projected-inventory report open next to the Planning Worksheet for exactly this reason — and one of them turned that Power BI report into “the most used report in the organization.” [11] The parameter treadmill is not a configuration problem. It is the operator’s status quo on a mid-market BC tenant.

What Isovel decides — and writes back to BC

Isovel sits on top of Business Central as a planning agent. It connects via Office 365 SSO and BC’s documented OData and Web Services surfaces — no consultant, no migration, no new planning surface to maintain in parallel. [12] Once connected, three things happen continuously:

1. The 17 planning parameters are derived from your sales data. Reorder Point, Safety Stock Quantity, Reorder Quantity, Reordering Policy, Dampener Period, Time Bucket, Safety Lead Time, and the rest — the agent computes each one per SKU per location from your actual demand, lead-time history, and service-level target. Your planner is not asked to enter them, maintain them, or re-set them when something drifts. They update on the agent’s own clock.

2. The agent decides what to order and what to transfer. Purchase order automation is first-class: PO recommendations respect Minimum Order Quantity from your BC vendor cards and container or pallet-rounding constraints at the DC level — full-pallet and full-container ordering arrive pre-rounded, not as a math problem for the planner. Transfer Order recommendations reason across every BC location: per-location forecast, per-location stock, per-location service level, and lateral demand all feed the same decision. The agent surfaces multi-warehouse imbalance automatically when the tenant has two or more locations.

3. Recommendations land in BC as draft worksheet lines — approval-gated by default, idempotent, reversible. Recommendations write back to BC’s Requisition Worksheet as draft planning lines that your planner Carries Out via BC’s standard approval and document-commit workflow. Re-running a planning generation never duplicates write-backs — the underlying BC Demand Forecast Entry table is not idempotent at the platform layer (a 2026 r/Dynamics365 operator documented that “importing a Demand Forecast with RapidStart creates duplicate entries”), [13] so the calling agent has to enforce idempotency, and Isovel does. Every action is reversible within a 24-hour rollback window. Every recommendation and every write-back is audit-logged with the agent’s rationale string attached.

Industry data on mid-market wholesale distribution converges on a single anchor: SMB inventories carry roughly 38% excess stock — per Netstock’s 2024 Inventory Management Benchmark Report on n=2,400 customers. [3] Carrying that excess costs you 15–25% of inventory value per year in storage, capital, obsolescence, and insurance. [4] The agent’s job is to make the gap visible on your tenant, in your data, in the first ten minutes — then close it, week by week, decision by decision, with the rationale on every line so your planner can audit the reasoning before approving. That is the agentic supply chain planning category, and it is what Isovel is built for.

Multi-location transfer reasoning

MVP Tier 0

Cross-location transfer recommendations are first-class output alongside purchase orders. BC’s planning engine emits Transfer as one of its four action verbs, [6] and BC ships a useful primitive called Combine Transfer Orders that consolidates multiple transfer suggestions for the same source-destination pair into one transfer order — “If ticked, then all supplies being transferred between the same locations will be consolidated into a single transfer order.” [14] That primitive is good — Isovel writes into it, not against it. BC’s Combine Transfer Orders downstream still operates as it always has on the lines Isovel recommends.

The deciding work above the primitive is where the agent earns its keep. Which transfer to recommend in the first place — given today’s per-location demand pattern, today’s stock distribution, today’s per-location service level — is exactly the reasoning BC’s planning surface leaves to the planner. A BC expert in a 2026 r/Dynamics365 thread put the gap flatly: “there is no capability in the system to say ‘consolidate into a location which already contains the item, but exclude the location it’s being picked from.’” [15] Isovel’s transfer recommendations reason about which inter-location moves close imbalance without depleting the source, and surface them with rationale.

For the deeper architectural picture of the rebalancing engine, see /multi-location-inventory-rebalancing/.

The trust controls — approval-gated by default, permanent

BC’s Planning Worksheet has a field called Accept Action Message. By default, it is TRUE for every planning line with no warnings — meaning Carry Out Action Message executes every warning-free suggestion across the planning horizon in a single click. A community blog author documented writing an AL codeunit modification to invert the default to FALSE, because the auto-accept-all behavior was so dangerous in production that planners “only want to accept the suggestions that has an order date within the next couple of weeks.” [16]

Isovel’s default polarity is the opposite. Every recommendation is approval-gated by default at the start. The trust primitives — pause, stop, rollback, restore manual approval — are permanent and cannot be removed. The autonomy of the agent is graduated independently: as your planner gains comfort with the agent’s track record, the default-required-approval-per-action can loosen step by step (a planner can opt into auto-execute for transfer orders below a value threshold after a track record of correct recommendations, for instance). But the planner can always restore explicit approval, pause the agent, or roll back any action within 24 hours.

Autonomy loosens in small steps, never in one jump — just enough that the planner stays comfortable with the actions the agent is taking on the tenant’s data. Transparent, auditable, and reversible are non-negotiable when an agent writes back to an ERP of record.

Production Orders and Assembly Orders today

Isovel today decides and writes back Purchase Orders and Transfer Orders only — two of the four action types BC’s planning engine emits. [6] Production Orders and Assembly Orders continue to flow through your BC Planning Worksheet as before. We do not auto-decide shop-floor orders or write back Production Order or Assembly Order lines on the current MVP scope.

Agent decisioning for shop-floor orders ships with Phase 2, alongside our Beachhead #2 expansion into BOM-driven make-to-stock light manufacturing on Business Central. Until then, Isovel sits in the planning lane and stays out of the shop-floor lane. If your replenishment workload is mostly Purchase and Transfer, you are in the Phase 1 MVP. If it is mostly Production and Assembly, wait for Phase 2 — we would rather you wait than ship you the wrong product.

Replaces the Enhanced Planning Worksheet (Insight Works)

The Enhanced Planning Worksheet from Insight Works is the BC-native incumbent on the replenishment surface. EPW positions on “Automated Order Triggers — Utilizes set thresholds to initiate purchase or transfer orders, keeping inventory levels balanced,” and “Multi-Location Inventory Coordination — Manages inventory across multiple locations, optimizing space and reducing redundancy.” [19] Threshold automation on top of a display layer is a meaningful improvement over BC standard. It is not the same thing as a decision agent.

Isovel does not stack on top of EPW. Both products would otherwise compete for ownership of BC’s planning-line write-back path. Onboarding detects EPW and walks you through disabling it before write-back is enabled. The head-to-head — threshold-set automation vs. agent-derived continuous parameter derivation, display-and-trigger vs. decide-and-write-back — lives at /alternatives/insight-works/.

Why Netstock and EazyStock aren’t this

The BC replenishment ISV landscape comes in three tiers.

Parameter automation — EazyStock. Their published positioning, verbatim: “In contrast, EazyStock calculates all orders automatically and continuously adjusts the parameters that drive recommendations.” [20] Auto-tune the inputs the BC worksheet consumes; the planner still operates the BC worksheet, and now also operates EazyStock’s separate planning surface.

Recommendation surfacing — Netstock. Netstock now writes back approved purchase orders to BC and now leads with AI in their corporate positioning. The 2026 wedge against Netstock is not “we write back, they don’t” — that’s no longer true. It is closed-loop agentic decisioning (Isovel decides at the agent level) vs. recommendation-and-approval-surfacing (planner reviews each Netstock-generated suggestion before approving). It is real-time vs. T+1 ERP sync — a December 2025 Capterra reviewer noted “being 1 day behind our ERP, has been a challenge in the scheduling of our processes.” [21] It is zero-setup vs. 4-6-week implementation with item classification and rule setup. And it is replacement rather than enhancement, per Isovel’s standing replace-don’t-coexist posture.

Decision agent — Isovel. The agent derives the 17 parameters continuously; decides per-SKU per-location what to order and what to transfer; writes draft lines back to BC’s Requisition Worksheet, approval-gated, idempotent, audit-logged, 24-hour reversible. One agent, BC-embedded, <10 minutes from connector install to first actionable recommendation.

The category gap is structural. The cluster’s published vendor positioning describes automation in every flavor — threshold automation, alert automation, parameter automation, order automation. None of them describes their product as removing the planner from the deciding loop while preserving an explicit approval gate. That gap is the wedge Isovel is built for. For the head-to-head, see Netstock alternative for BC.

Watch the agent decide on your BC data — read-only for 30 days. Get early access →

Business Central replenishment FAQ

1. Does Isovel replace the Planning Worksheet and Requisition Worksheet in BC? Functionally yes for Purchase and Transfer Orders. Both worksheets still exist in BC as the surface where draft lines land for the planner to review. Isovel writes draft lines into the Requisition Worksheet that BC’s standard Carry Out Action Message workflow then processes — the planner’s hand is on the same lever as before. The behavior change is upstream: instead of the planner authoring 17 parameters per SKU and reviewing thousands of action messages, the agent has derived the parameters and decided which lines belong on the worksheet.

2. What about Production Orders and Assembly Orders? Phase 2. Today, Isovel decides and writes back Purchase Orders and Transfer Orders only — two of the four action types BC’s planning engine emits. [6] Production Orders and Assembly Orders continue to flow through your BC Planning Worksheet as before. Agent decisioning for shop-floor orders ships with our Beachhead #2 expansion into BOM-driven make-to-stock light manufacturing.

3. Does Isovel work alongside Microsoft Copilot for Business Central? Yes. Microsoft’s own May 2026 Copilot for Business Central FAQ states that “forecasting features [in Business Central] aren’t related to Copilot.” [22] Copilot accelerates routine in-system tasks and narrates BC data in natural language. Isovel decides replenishment and writes draft orders back to BC. The two products do different work and do not overlap.

4. What happens if Isovel’s recommendation is wrong? Three things. (a) Approval-gated by default — nothing writes to BC without your planner’s explicit approval at the start, and the approval gate is a permanent trust primitive. (b) Reversible — every action is reversible within a 24-hour rollback window. (c) Audit-logged — every recommendation and every write-back is visible in the audit trail with the agent’s rationale string attached, so you can audit why the agent decided what it decided before deciding whether to keep the write.

5. How does Isovel handle MOQs and container or pallet rounding? Both are honored. The agent reads Minimum Order Quantity from BC vendor cards and applies container or pallet-rounding constraints at the DC level — full-pallet and full-container ordering arrive pre-rounded. Recommendations land as draft PO lines that already respect these constraints; no manual round-up by the planner.

6. Does Isovel recommend transfers between locations? Yes. Transfer-order recommendations are first-class output alongside Purchase Orders, reasoned from per-location forecast, per-location stock, per-location service level, and lateral demand. Isovel’s recommendations write into BC’s transfer-order surface, and BC’s Combine Transfer Orders consolidation step continues to operate downstream exactly as it does today. Honored, audit-logged, reversible like every other write-back.

7. Are Isovel’s write-backs idempotent? Yes. Re-running a planning generation never duplicates write-backs. This matters because BC’s underlying Demand Forecast Entry table is not idempotent at the platform layer — a 2026 r/Dynamics365 operator documented that “importing a Demand Forecast with RapidStart creates duplicate entries.” [13] The calling engine has to enforce idempotency, and Isovel’s write-back layer does.

8. Which versions of Business Central does this work with? Business Central 25, 24, and 23. Cloud (SaaS) at launch; on-premises is on the roadmap. The connector authenticates via Office 365 SSO and uses BC’s documented OData and Web Services surfaces plus the Requisition Worksheet write-back endpoints.

The 17 parameters the agent derives are the same 17 a BC planner has been maintaining by hand

The 17 fields the agent derives — Reordering Policy, Reorder Point, Reorder Quantity, Safety Stock Quantity, Dampener Period, Time Bucket, Safety Lead Time, and the rest of the planning-parameter and order-modifier set — are the exact same fields a mid-market BC planner has been hand-tuning on every Item or SKU card for years. The agent replaces the parameter-treadmill work, not the planner’s judgment over what the agent’s draft lines should become. Every draft purchase order and transfer order writes back to the Requisition Worksheet your planner already uses, with the agent’s rationale string attached so the reasoning is auditable before approval.