DEV Community: Dean Fachrie

Master planning (MRP) module in Dynamics 365 F&O and SAP S/4HANA

Dean Fachrie — Mon, 14 Sep 2026 21:11:48 +0000

Nine of SAP's ten lot-sizing procedures transfer to Dynamics 365 F&O more cost-effectively than before. The tenth incurs a 3 per cent increase, and only if the coverage period is adjusted afterwards.

CodeCore Dynamics LLC. 14 September 2026.

Summary

Last week, this series noted that Dynamics 365 F&O and Infor LN size replenishment orders almost identically because LN's lot-sizing set aligns closely with F&O's. SAP's set does not.
SAP groups lot sizing into three families. F&O provides rules in only two of them. The third reads a cost and picks a lot size from it.
The literature suggested the missing family would stop mattering once the plan was rebuilt weekly against an imperfect forecast. It did not. Part Period Balancing costs 8.8 to 29.2 per cent less than the best rule F&O offers across four of five business cases, moving only 6.7 per cent when given an order cost anywhere from half to twice the actual figure.
The cost gap reflects a single coverage period applied across the entire catalogue. Setting the period per item closes a third to a half of the gap and beats SAP outright on spare parts and long lead times.
Demand class is the wrong attribute to adjust, performing worse than a single catalogue-wide value in two of five cases. Deriving the period from each item's price and demand rate closes 28 to 45 per cent of the gap.
Of ten SAP lot-size keys migrated into F&O, only Part Period Balancing incurs a cost (3.3 per cent). Retaining one coverage period across the catalogue raises that cost to 27.6 per cent.
SAP can place the receipt at the start, the first requirement, or the end of the bucket. F&O has one position, which is the best of the three. A period-end receipt costs up to 51.6 points of fill.
Nothing here supports a migration from F&O to SAP S/4HANA on planning grounds.

Reading Guide

You want	Read
Settings to apply in F&O	Section 5.2
Recommendations	Section 5.3
SAP lot-size key costs landing in F&O	Section 4.4
Base of recommendations	Section 4
Model checking	Sections 3.3 and 3.4
Questions for planning team	For Finance Leadership
What is not covered	Limits
To reproduce the analysis	Reproducing This

Table 1. Section 5.2 and Section 5.3 for the recommendations. Section 4 for the evidence.

For Finance Leadership

Three questions establish the exposure without opening the system.

Ask	Warning sign	Cost impact
How many distinct coverage periods are set across the item master?	One value applied universally	Up to 27.6 per cent of ordering and holding cost against a per-item setting
What order cost was used to choose them?	The question is not understood	Correct period ranged 7 to 168 days across the order costs tested. F&O records no such cost
For items arriving from SAP, which lot-size key did they carry?	The mapping was not retained	Only one of ten keys costs anything to lose

The running cost converts from two figures already on the books. Each order saved is one fully loaded purchase order raised. Each unit-day of stock removed is unit cost multiplied by the holding rate. Both inputs belong to your organisation and are not supplied here.

Nothing in this article supports a migration to SAP S/4HANA on planning grounds. The evidence solely supports deciding whether the coverage period is tuned after a move, which is a configuration task rather than a licensing issue.

Terms

Dynamics 365 F&O

Term	Meaning
Master planning	Reads demand and supply, proposes orders
Planning Optimization	Current master planning engine. Runs outside the application
Coverage code	Lot-sizing method for an item. Per requirement, Per period, Min/Max, Priority, Decoupling point, Manual
Coverage period	Days of demand one order covers under Per period
Item coverage, coverage group	Where coverage settings live. Item coverage overrides coverage group

SAP S/4HANA

Term	Meaning
MRP Live	Current planning run. Executes in the database
Lot-sizing procedure	Procurement quantity rule. MRP 1 view
Lot-size-independent costs	Cost of raising one order. Material master
Storage costs indicator	Annual storage cost as a percentage of material price
Scheduling indicator	Where the receipt lands inside a period
Short-term and long-term lot size	Two lot-sizing procedures on one material, split by date

The Planning Words

Term	Meaning
Lot sizing	Deciding how much goes on one order
Net requirement	What is still short once stock on hand and orders already placed are counted
Bucket	A block of days whose demand is put on a single order
Lead time	Days between placing an order and it arriving
Replanning	Throwing the plan away and rebuilding it from current numbers. Weekly, here
Forecast error	How wrong the demand forecast is, as a percentage

How Items Behave

Term	Meaning
Smooth	Sells most days, in similar quantities
Erratic	Sells most days, in quantities all over the place
Intermittent	Sells rarely, in similar quantities
Lumpy	Sells rarely, and in quantities all over the place

Measurement

Term	Meaning
Fill rate	The share of units that were available on the day they were required to be
Points	Percentage points. Dropping from 100 per cent fill to 48.4 per cent is a fall of 51.6 points
Days of cover	How many days the stock on hand would last at normal demand
Unit-day	One unit sitting in the warehouse for one day. Storage cost is charged per unit-day
Cost	Ordering cost plus storage cost
Service floor	A rule had to serve 95 per cent of demand before its cost was allowed to count. Cheap and out of stock is not cheap

1. The Boundary

Master planning addresses what quantity needs ordering and when given current on-hand stock, existing orders, and expected demand. Most implementations run the process nightly, discarding previous proposals to rebuild them.

Both products net requirements identically before determining order quantities. That quantity calculation forms the entire scope of this evaluation.

Two specific boundaries apply. The SAP comparison uses S/4HANA 2025 on-premise and private cloud; the public cloud edition is excluded. Additionally, the analysis evaluates SAP's MRP lot-sizing procedures rather than PP/DS. PP/DS provides distinct planning capabilities via dedicated heuristics and an optimiser that accounts for "penalties (safety stock, maximum stock), costs (procurement, production, storage) and constraints (production capacity and lot sizes)". Implementations utilising PP/DS fall outside this measurement, and F&O offers no direct equivalent.

flowchart LR
    N[Net requirement<br/>on a date] --> Q{What sets<br/>the quantity?}
    Q --> A[Dynamics 365 F&O]
    Q --> B[SAP S/4HANA]
    A --> A1[Window opens at<br/>the first demand]
    A --> A2[Receipt lands on<br/>the first day of the window]
    B --> B1[Window may be anchored<br/>to a calendar]
    B --> B2[Receipt may sit at the start,<br/>the first requirement,<br/>or the end]
    B --> B3[A cost may choose<br/>the quantity]

    classDef fno fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b
    classDef sap fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef neutral fill:#ffffff,stroke:#52514e,color:#0b0b0b
    class A,A1,A2 fno
    class B,B1,B2,B3 sap
    class N,Q neutral

Figure 1. Blue is what F&O does and cannot be told to do otherwise. Amber indicates settings only SAP carries. Each amber box is tested in Section 4.

2. Capabilities Compared

2.1 The Families

SAP states "Three groups of lot-sizing procedures are available: Static lot-sizing procedures, Period lot-sizing procedures, Optimum lot-sizing procedures."

flowchart TD
    ROOT[Lot-sizing procedures] --> ST[Static<br/>quantity from the material master]
    ROOT --> PE[Period<br/>group requirements in an interval]
    ROOT --> OP[Optimum<br/>group until a cost criterion is met]

    ST --> S1[EX Lot-for-lot = Per requirement]
    ST --> S2[HB Replenish to maximum = Min/Max]
    ST --> S3[FX Fixed lot size]
    PE --> P1[TB daily, WB weekly, MB monthly,<br/>posting period, planning calendar]
    PE --> P2[F&O: Per period, in days,<br/>opening at the first demand]
    OP --> O1[SP Part Period Balancing]
    OP --> O2[WI Sliding Economic Lot Size]
    OP --> O3[DY Dynamic Planning Calculation]
    OP --> O4[GR Groff Reorder Procedure]
    OP --> O5[F&O: nothing]

    classDef both fill:#dcecdc,stroke:#3a7d3a,color:#0b0b0b
    classDef sap fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef fno fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b
    classDef gone fill:#f6d8d4,stroke:#b0443a,color:#0b0b0b
    classDef root fill:#ffffff,stroke:#52514e,color:#0b0b0b
    class ROOT,ST,PE,OP root
    class S1,S2 both
    class S3,P1,O1,O2,O3,O4 sap
    class P2 fno
    class O5 gone

Figure 2. Green is the same mechanism in both products. Amber is documented only by SAP. Blue is the F&O rule in that family. Red is the family F&O has no rule in.

On the optimum family, SAP explains what the other two categories omit: "In static and period lot-sizing procedures, the costs resulting from stockkeeping, from the setup procedures or from purchasing are not taken into consideration." The four variants differ only in where they stop, as "The only differences between the various optimum lot-sizing procedures are the cost criteria."

All four read three material master fields: price, lot-size-independent costs, and the storage costs indicator. F&O carries none of these for planning purposes.

2.2 Receipt Position

SAP's period procedures group requirements within a calendar interval, which can be a day, a week, a month, a posting period, or an entry in a planning calendar. F&O's period operates differently: "The period starts with the first demand of the item and covers the defined length in time. The next period starts with the next requirements of the item."

SAP also determines where within the interval stock becomes available: "The system sets the availability date for period lot-sizing procedures to the first requirements date of the period. However, you can also define that the availability date is at the beginning or end of the period." F&O uses a single fixed position: "The order is planned for the first day of the period."

2.3 Near and Far Horizon

SAP can plan the near horizon with one procedure and the far horizon with another. The stated purpose is to "group together requirements over a larger period in the long-term area to produce a rough picture of the future master plan and select a more precise lot size to suit your requirements in the short-term area."

F&O applies a single coverage code per item across the entire horizon.

2.4 Contrast Not Modelled

Mechanism	SAP S/4HANA	Dynamics 365 F&O
Planning run selection	MRP type on the material master	Coverage code, and the plan the item sits in
Near-horizon protection	Planning time fence with firming types	Freeze time fence. Auto-firming is a separate batch job
Rounding	Rounding value and rounding profile	Multiple on default order settings
Bring requirements forward	Safety time	Safety margins
Dynamic safety stock	Range of coverage profile	Minimum coverage, minimum and maximum keys
Planning scope	Plant and MRP area	Site, warehouse, coverage dimension
Constrained planning layer	PP/DS. Heuristics, an optimiser, finite capacity	No equivalent. Finite capacity scheduling, but no cost objective

Table 2. Nothing in this table is measured in Section 4. It is here so the comparison is not read as complete.

Both vendors transitioned planning to new engines and published the underlying changes. SAP's Simplification List states that "The S/4HANA MRP only plans on plant and MRP area level", making storage location MRP "a subset of the MRP areas capabilities". Microsoft's Planning Optimization fit analysis notes that a freeze time fence set on item coverage "is ignored when Planning Optimization is enabled", and that sales line reservation via explosion alongside intercompany planning execution remain unsupported.

3. Data and Method

3.1 Source

Demand data originates from Online Retail II, a transaction dataset from a UK-registered non-store online retailer selling giftware primarily wholesale, published via the UCI Machine Learning Repository under CC BY 4.0. It contains 1,067,371 rows spanning 1 December 2009 to 9 December 2011.

This matches the dataset used in the Infor LN study. Reusing the same demand and testing framework while changing only the vendor ensures any variance in results stems directly from software rules rather than the underlying data.

Every invoice line includes a unit price, allowing storage costs to reflect actual prices charged. The median item sells at £2.10, with the 5th to 95th percentiles ranging from £0.42 to £10.75.

3.2 Filters

Stock codes consisting of five digits with an optional letter suffix are retained, filtering out postage, adjustments, bank charges, and samples. Credit invoices and negative quantities are removed from demand. Items qualify for replay if they record 12 or more demand days within a 180-day active window, leaving a working set of 3,498 items.

3.3 The Objective

Because SAP's optimum procedures aim to minimise order and storage costs, performance is evaluated on that metric. Total cost equals order cost multiplied by orders raised, plus the storage cost of every unit-day held based on the item's unit price.

Cost alone cannot determine rank. Min/Max achieved the lowest cost in two business cases while serving only 83 to 84 per cent of demand, because an objective focusing strictly on orders and holding costs ignores stockouts. All rankings in this study consider only rules achieving at least a 95 per cent fill rate. Standard lot-sizing literature assumes no backlogging, making cost comparisons between rules that fail to serve demand analytically undefined.

3.4 Verification

SAP provides a worked example on each optimum lot-sizing documentation page, including inputs and expected outputs. All four procedures share identical test parameters: price 20, lot-size-independent costs 100, storage 10 per cent, and demand of 1,000 units on four weekly dates.

Procedure	SAP published result	Test implementation result
Part Period Balancing	2000	2000
Sliding Economic Lot Size	2000	2000
Dynamic Planning Calculation	3000	3000
Groff Reorder Procedure	1000	1000

Table 3. Four procedures, three distinct answers on one example. An implementation that confuses two of them fails here.

The Groff documentation details its two comparison metrics: a cost saving of 1.79 against an additional storage expense of 19.18. Both figures reproduce accurately. They also clarify how annual storage percentages divide across daily increments: at 365 days the figure equals 19.18, whereas at 360 days it equals 19.44.

Structural conditions validate the model: no rule may cost less than the Wagner-Whitin optimum, a one-day bucket must equal one order per requirement, a calendar-anchored plan must remain static given a perfect forecast, and rerunning the process independently must reproduce identical stored results. Compared against ONS series J596, the retailer's monthly revenue correlates at 0.858 over 23 overlapping months, with both series peaking in November.

3.5 Initial Expectations

Existing research suggests clear outcomes. Blackburn and Millen demonstrated that under rolling schedules, the simpler Silver-Meal heuristic can outperform the Wagner-Whitin algorithm, indicating that single-pass proximity to the theoretical optimum offers limited predictive value. Wemmerlöv established that forecast errors diminish performance gaps between procedures. Zoller and Robrade surveyed the same family and recommended adopting "Groff's (1979) stop rule".

The working hypothesis assumed SAP's optimum procedures would lose most of their advantage when rebuilt weekly against an imperfect forecast, losing the remainder when input order costs differed from actual costs by a factor of two. Section 4.1 outlines the actual findings.

3.6 Business Cases

Case	Lead time	Forecast error	Item selection source
Fast-moving distributor	5 days	10%	Smooth and erratic
Long-lead importer	60 days	20%	All classes
Spare parts operation	45 days	30%	Intermittent and lumpy
Seasonal wholesaler	20 days	20%	All classes
Volatile demand	14 days	40%	Erratic and lumpy

Table 4. Each case replans weekly over two years, after a warm-up that is discarded.

4. Results

4.1 The Missing Family

Figure 3. Part Period Balancing is cheapest in four of the five cases. Spare parts is the exception, where it is the most expensive rule tested.

The initial expectation proved incorrect. Under weekly replanning with forecast error, ranked among rules clearing the service floor, Part Period Balancing costs less than anything F&O can express across four of five business cases.

Business case	Best rule F&O has	F&O costs
Fast-moving distributor	Per period 14d	29.2% more
Seasonal wholesaler	Per period 7d	27.8% more
Volatile demand	Per period 14d	21.8% more
Long-lead importer	Per period 14d	8.8% more
Spare parts operation	Per period 56d	best available

Table 5. Cost is order cost plus storage cost over the measured window, among rules serving at least 95 per cent of demand.

The spare parts case aligns with the literature's prediction. On intermittent and lumpy demand with a 45-day lead time, Part Period Balancing is the most expensive rule tested, holding three times the stock of a 56-day coverage period for the same order count. A rule committing large lots early cannot recover when the underlying signal shifts.

Figure 4. The coverage periods are flat because they read no cost. Part Period Balancing moves 6.7 per cent across a fourfold error in the one it does read.

The order cost also decides what the best coverage period is, which matters because F&O holds no field for it.

Assumed order cost	Best single coverage period
0.25	7 days
1	14 days
5	42 days
15	84 days
50	168 days

Table 6. The assumed order cost moves the best coverage period from 7 days to 168. F&O records no such cost.

The second assumption proved incorrect as well. Given an input order cost ranging from half to double the actual value, Part Period Balancing shifts by only 6.7 per cent, with the best SAP procedure maintaining a 27 to 28 per cent advantage over the best coverage period at every level. The cost curve near an economic order quantity is flat, so doubling input cost alters quantity by its square root and shifts total cost minimally. Dynamic Planning Calculation is the exception at 57.8 per cent, as its criterion acts as a strict threshold against order cost rather than a balance around it.

4.2 Anchoring Against Placement

Two distinct variables separate F&O's Per period from SAP's period procedures: bucket boundary positioning (anchoring) and receipt placement within the bucket (placement). Isolating these variables demonstrates their individual impact.

Figure 5. Three of the four series sit on 100 per cent fill and overlap on the right panel. Only the period-end receipt separates, and it separates a long way.

Anchoring exerts minimal effect. Holding receipt timing to the first requirement, a calendar-anchored bucket alters cost by between minus 0.6 and plus 7.1 per cent, leaving fill rate unchanged. It holds 11 to 17 per cent less stock while raising 6 to 33 per cent more orders.

Figure 6. The penalty rises with weekday concentration at short buckets, which is the mechanism, and stays under 12 per cent throughout, which is the size of it.

Placement exerts a major effect.

Bucket	Stock at period start	Fill at first requirement	Fill at period end	Points of fill lost
7 days	+24.4%	100.0%	76.6%	23.4
14 days	+20.5%	100.0%	72.1%	27.9
28 days	+27.1%	100.0%	63.7%	36.3
56 days	+27.0%	100.0%	48.4%	51.6

Table 7. Stock is against the same bucket receiving at its first requirement, at unchanged service. The last column is the fill rate given up by moving the receipt to the end of the period.

Moving the receipt to the start of the period holds 20 to 27 per cent more stock and serves no better. Moving it to the end of the period costs service, and costs more of it the longer the bucket, because the stock arrives after demand earlier in the same bucket has already been required. At a 56 day bucket that is 51.6 points of fill.

F&O provides a single fixed position: the default setting shipped by SAP and the best-performing of the three tested.

4.3 The Far Horizon

Figure 7. Below a lead time that reaches past the switch date, every item is unaffected. Above it, none are.

SAP's short-term and long-term split yields no difference until item lead time exceeds the near-horizon window. At lead times of 5, 14, and 20 days against a switch at 28 days, every item generates identical outcomes. At a 45-day lead time, 1 per cent show variation. At 60 days, all items vary, with the broader far-horizon rule saving 23 per cent of cost and over a point of fill rate.

Far-horizon proposals are continually recalculated before release unless lead time extends past the switch boundary to force execution.

4.4 Cost on Arrival

Figure 8. Only Part Period Balancing costs anything to lose, and only when the coverage period is set per item. Leaving one value across the catalogue costs up to 27.6 per cent.

SAP key	Procedure	F&O	Tuned per item	One setting
EX	Lot-for-lot order quantity	Per requirement	−67.4%	−59.7%
TB	Daily lot size	Per period 1d	−67.4%	−59.7%
HB	Replenish to maximum	Min/Max	−44.6%	−0.4%
FX	Fixed lot size	no equivalent	−36.4%	−21.4%
MB	Monthly lot size	approximate	−35.5%	−20.4%
WB	Weekly lot size	approximate	−20.9%	−2.3%
WI	Sliding Economic Lot Size	no equivalent	−13.3%	+7.0%
DY	Dynamic Planning Calculation	no equivalent	−12.3%	+8.3%
GR	Groff Reorder Procedure	no equivalent	−0.0%	+23.4%
SP	Part Period Balancing	no equivalent	+3.3%	+27.6%

Table 8. A negative figure means the F&O substitute costs less than the SAP key it replaces. One business case, 200 items.

4.5 Tuning Rules

The tuned column above calculates each item's optimal coverage period ex post, serving as a theoretical bound rather than an operational method. Testing evaluated two executable tuning methods against this baseline.

Assigning coverage periods by demand class fails. Applying the median best period for each class yields results worse than a uniform catalogue-wide setting in two of five cases, expanding the cost gap by 199 and 301 per cent. Demand class is not an intrinsic item property; a period suited to intermittent demand with a 45-day lead time performs poorly when applied behind a 14-day lead time.

Deriving coverage periods from each item's economic order quantity succeeds. Calculating values from item price, demand rate, and an assumed order cost, rounded to the nearest available period, bridges 28 to 45 per cent of the cost gap in four of five business cases.

Business case	One coverage period	Set from economic order quantity	Gap closed
Fast-moving distributor	+25.9%	+15.8%	39.0%
Long-lead importer	+7.1%	+4.4%	38.3%
Seasonal wholesaler	+27.3%	+19.5%	28.5%
Spare parts operation	−45.1%	−24.7%	45.2%
Volatile demand	+21.8%	+22.3%	−2.0%

Table 9. Cost against Part Period Balancing in the same case. A negative figure means the F&O rule is cheaper. Volatile demand is the case where the rule does not help.

Figure 9. The left panel shows each class has a different best period. The right panel shows the spread inside each class is wide enough that the class alone does not determine it.

5. Discussion

5.1 Key Substitution

flowchart TD
    K[SAP lot-size key<br/>on the MRP 1 view] --> F{Which family?}
    F -- Static --> S{Which rule?}
    F -- Period --> P[Set Per period to the<br/>bucket length in days]
    F -- Optimum --> O[No coverage code reads a cost]
    S -- EX --> S1[Per requirement. Exact]
    S -- HB --> S2[Min/Max. Exact]
    S -- FX --> S3[No coverage code fixes a quantity]
    P --> P1[Boundary floats, does not anchor.<br/>Costs under 8 per cent]
    O --> O1[Derive the period from the item's<br/>own price and demand rate]
    S3 --> O1
    O1 --> R[Only Part Period Balancing<br/>costs anything. 3.3 per cent]

    classDef ok fill:#dcecdc,stroke:#3a7d3a,color:#0b0b0b
    classDef warn fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef act fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b
    classDef dec fill:#ffffff,stroke:#52514e,color:#0b0b0b
    class S1,S2,R ok
    class S3,O,P1 warn
    class P,O1 act
    class K,F,S dec

Figure 10. Green is a no-cost substitution. Amber is an exclusive SAP mechanism. Blue is the gap-closing action.

5.2 Configuration

Identify the exposure first. Running a simple setup table report without transaction history highlights potential gaps. Counting distinct coverage periods across the item master is the check; one value across an entire mixed catalogue is the finding.

Setting	Where	What to put in it
Coverage period	Master planning > Setup > Coverage > Coverage groups. Item coverage for a single item	Derived per item from unit price and demand rate. Not from demand class, not one value for the catalogue
Coverage code	The same two places	Per period for SAP period and optimum keys. Per requirement for EX. Min/Max for HB

Avoid assigning coverage periods via demand classification. Section 4.5 demonstrates that classification performs worse than a single uniform setting in two out of five business cases, while prior findings show that class boundaries shift depending on the review period measured.

Record the underlying order costs used to derive coverage periods outside the application, as F&O lacks dedicated fields for these values and optimal periods depend directly on them. Across tested scenarios, optimal periods ranged from 7 to 168 days based on order cost variables.

For items migrating from SAP, verify scheduling indicators before assuming equivalent planning execution. Where SAP setups used period-end scheduling, single-level demand fulfilment fell materially below 100 per cent; the F&O substitute will serve more.

5.3 For Microsoft

Evaluated SAP capabilities and the corresponding requirements for F&O parity.

SAP capability	Worth having?	Evidence	Request for F&O
Optimum lot sizing	Yes	8.8 to 29.2 per cent of cost in four of five cases. Holds across a fourfold error in the order cost	Coverage code that reads a cost. Failing that, the two fields it needs
Lot-size-independent cost and storage percentage on item master	Yes, and cheaper to ship	Best coverage period ranged 7 to 168 days across order costs. Per-item derivation closes 28 to 45 per cent of the gap	Two fields on item coverage, and a coverage period derived from them
Calendar-anchored buckets	Marginal	Under 8 per cent of cost, reaching 12 per cent only where demand concentrates on one weekday	Optional calendar anchor on the coverage period. Low priority
Short-term and long-term lot size	Only for long lead times	Nothing where the lead time falls inside the switch date. 23 per cent of cost and over a point of fill at 60 days	Second coverage period beyond a configurable day count
Fixed lot size	No	A tuned coverage period costs 36.4 per cent less than the SAP key	None
Receipt placement	No	F&O's one position is the best of the three. Period end loses up to 51.6 points of fill	None. Worth not having
Freeze time fence on item coverage	Not measured	Microsoft's own fit analysis records it as ignored	Honour it, or remove the field

The primary enhancement involves creating a coverage code capable of evaluating cost variables. Alternatively, providing the two underlying cost fields on the item master allows deriving significantly improved coverage periods within existing rules, as demonstrated in Section 4.5.

5.4 Claims and Sources

Claim	Source
Part Period Balancing costs 8.8 to 29.2 per cent less than the best F&O rule in four of five cases	Data
Part Period Balancing shifts by 6.7 per cent when input order costs vary by a factor of two	Data
Part Period Balancing represents the highest-cost rule for intermittent demand with 45-day lead times	Data
Anchoring impacts total cost by under 8 per cent, increasing only with high weekday demand concentration	Data
Period-end receipt scheduling reduces fill rate by up to 51.6 points	Data
Long-term lot sizes yield no operational difference when lead times fall within the switch boundary	Data
Nine of ten SAP lot-size keys execute more cost-effectively in F&O once coverage periods are tuned per item	Data
Demand classification fails as a tuning rule; economic order quantity logic succeeds	Data
Which lot-sizing procedures each product offers	Documentation
Everything in Table 2	Documentation

Table 10. Eight findings from the data. The capability tables from the two vendors' published manuals.

Neither dynamic SAP nor live F&O environments were executed directly. Both rule sets reflect reimplementations of documented behaviour; functionality deviating from published vendor specifications falls outside the scope of this model.

Limits

This evaluation excludes PP/DS, which executes constrained planning using capacity and cost optimisation functions not modelled here. Findings apply strictly to standard MRP 1 lot-sizing procedures.

The dataset reflects a single wholesale order profile lacking multi-level bills of materials, routings, or capacity constraints. Results do not evaluate dependent demand, multi-level netting, or production scheduling, restricting conclusions to purchasing and distribution scenarios. Furthermore, period-end receipt outcomes reflect single-level calculations; because SAP reschedules component requirements across bills of materials, multi-level structures will alter total cost impacts.

Order costs are not explicitly present within the transactional dataset. Values were evaluated across parameterised sweeps, forming the basis of Section 4.1. Assuming a fully loaded purchase order cost of £50, 98 per cent of catalog items imply reorder cycles exceeding any tested coverage period, as a £50 transaction cost against £3 of daily demand dictates infrequent replenishment. Practical wholesaling relies on order consolidation across multiple lines, which falls outside single-item lot-sizing logic in both platforms.

Groff's rule specification presents ambiguities in SAP documentation. Two distinct algorithmic interpretations reproduce published vendor examples due to single-step test parameters; however, across active transactional data, these interpretations diverge by a factor of two to three. This study applies the standard published stop rule throughout, providing the alternative logic within the source repository.

Plan stability measurements varied based on absolute versus relative tolerance thresholds applied prior to testing. Because threshold selection shifted rule stability rankings by up to five positions, explicit stability figures are omitted. SAP planning time fences and firming types mitigate replanning nervousness, but their precise financial impact is not quantified here.

Calculations depend on specific parameters that influence final values: a 20 per cent annual holding rate, parameterised order cost ranges, a 365-day annual divisor, a 95 per cent service floor target, weekly replanning intervals, a 28-day demand visibility window, 14 days of initial stock, filtering criteria (12 demand days across a 180-day active window), classification cutoffs (1.32 and 0.49), a weekly review period, and the operational parameters detailed in Table 4.

Reproducing This

The source code and datasets are at github.com/kingomnivore/mrp-fno-vs-sap. Clone it, pip install -r requirements.txt, then python run.py. Both data files are committed, so it runs as cloned.

The recipe below describes the same analysis independently of the code.

1. Get the data. Online Retail II from the UCI Machine Learning Repository, both sheets. ONS series J596, value not seasonally adjusted, for the external check.

2. Aggregate. Reduce the order lines to daily demand per item and a median unit price per item. Drop non-item codes, credit lines and negative quantities, then apply the activity filter.

3. Implement the rules. Code both vendors' lot-sizing procedures from their own documentation, including the ones the product under test does not offer.

4. Gate on the vendor's arithmetic. Reproduce SAP's published worked example for all four optimum procedures before running anything. Three distinct answers must come out of one example.

5. Replay. Define business cases as combinations of lead time, forecast error and item population. Run every rule in every case, replanning weekly, committing each order on its release date.

6. Cost it, then floor it. Order cost multiplied by orders, plus storage cost of every unit-day. Rank only among rules clearing a service floor.

7. Separate the variables. Test anchoring and receipt placement as a two-way design, not as two bundled configurations.

8. Sweep the cost inputs before reporting anything that depends on them.

Chosen parameters. As named in Limits.

On Method

The analysis code and the initial draft were produced with Claude Code. The dataset and the configuration claims were verified against the sources listed below before publication. The code is public on the repository.

Sources

Dynamics 365 Supply Chain Management documentation

SAP S/4HANA documentation, 2025 FPS01

Literature

Wagner, H. M. and Whitin, T. M. (1958). Dynamic version of the economic lot size model. Management Science 5(1). DOI 10.1287/mnsc.1040.0262 resolves to the 2004 reprint.
Blackburn, J. D. and Millen, R. A. (1980). Heuristic lot-sizing performance in a rolling-schedule environment. Decision Sciences 11(4).
Wemmerlöv, U. (1989). The behavior of lot-sizing procedures in the presence of forecast errors. Journal of Operations Management 8(1).
Zoller, K. and Robrade, A. (1988). Dynamic lot sizing techniques: survey and comparison. Journal of Operations Management 7(4).
Syntetos, A. A., Boylan, J. E. and Croston, J. D. (2005). On the categorization of demand patterns. Journal of the Operational Research Society 56(5).
Analysis code and data, GitHub

About Author

Dean Fachrie is a Functional Analyst at CodeCore Dynamics LLC, working on Microsoft Dynamics 365 F&O architecture and enterprise system design.

Migrating from SAP S/4HANA to Dynamics 365 F&O, or setting coverage periods across a mixed catalogue?

We help enterprise supply chain and finance teams map lot-sizing settings across ERP migrations and size replenishment against the working capital the business will carry.

Master planning (MRP) module in Dynamics 365 F&O and Infor LN

Dean Fachrie — Wed, 09 Sep 2026 21:40:20 +0000

Dynamics 365 F&O and Infor LN size replenishment orders almost identically. The difference is one F&O setting. The coverage time fence costs about half a point of service for every day it is set below the lead time, and raises no error.

CodeCore Dynamics LLC. 9 September 2026.

Summary

Master planning decides how much of the future to plan and at what resolution. The whole horizon at full detail returns proposals for orders that need no decision for months. Too short a horizon and long lead time items arrive late.
The two products agree almost entirely on lot sizing. One order per requirement, a floating time window and replenish-to-maximum exist in both. The window opens at the first demand in each, and neither product anchors it to the calendar.
LN adds Fixed Order Quantity and Economic Order Quantity. F&O adds priority-based replenishment and a decoupling point. Neither product contains the other's full set.
The setting to tune is how much demand one order covers. It is a working capital decision, not a service one. Doubling the window removes 39 per cent of the purchase orders and adds 126 per cent to the stock, at an unchanged fill rate.
The right window length differs by business. 56 days suited the spare parts operation, 7 and 14 days the short lead time cases.
Five business cases were built from two years of a UK wholesaler's order lines, and eleven lot-sizing settings ran in each. The floating window came top in all five. The two methods only LN documents never placed better than third of eleven.
Four of the five cases were ties, decided by 0.13 to 2.81 points on a hundred point scale. Only the spare parts case separated, at 9.93 points, and it went to a setting both products offer.
Service barely separates the time-phased rules at short lead times. Fill rate spread by under 0.2 points in three of the five cases, and by 2.8 and 4.3 points where the lead time reached 60 and 45 days.
LN's coarse planning tier is optional, set per item, and Infor advises against maintaining it unless its extra functionality is needed. An LN item planned only by order planning behaves as an F&O item does.
The coverage time fence is how many days ahead master planning reads supply and demand. Demand beyond it is not planned coarsely. It is not read, and nothing reports it. Microsoft's rule, that the fence exceed the total lead time, is correct, and ten days above it recovers almost all of the loss.
Nothing here supports a migration from F&O to Infor LN on planning grounds.

For Finance Leadership

The current position can be established without opening the system. Three questions to the planning team answer it.

Ask	Warning flag	Potential costs
What is the coverage time fence, in days?	A number at or below the longest purchasing lead time behind those items	Roughly half a point of fill for every day it falls short, with no error raised
Which items use the Period coverage code, and what period does each carry?	One value applied across the whole catalogue	The wrong stock and the wrong order count for whichever part of the catalogue it does not suit
What review period was the demand classification measured in?	Nobody knows, or it arrived with a reporting tool	Coverage codes assigned from a class that would change if it were measured weekly instead of monthly

The second answer converts to money from two figures already on the books. Moving the coverage period from 7 days to 28 days removed roughly two thirds of the purchase orders and roughly quadrupled the stock, at an unchanged fill rate. Multiply the orders saved by the fully loaded cost of raising one, and the stock added by unit cost and the holding rate. Those two inputs are yours and are not supplied here.

Nothing in this article supports a migration to Infor LN on planning grounds. The two lot-sizing methods F&O lacks were tested. Neither improved on the coverage codes F&O already ships.

Terms

Dynamics 365 F&O

Term	Meaning
Master planning	The calculation that reads demand and supply and proposes orders
Planning Optimization	The current master planning engine, run as a service outside the application
Coverage code	The lot-sizing method for an item. Period, Requirement, Min./Max., Priority, Decoupling point or Manual
Coverage period	The length in days that one order covers under the Period coverage code
Coverage time fence	How many days ahead supply and demand are read
Item coverage, coverage group	Where coverage settings are held, the first overriding the second

Infor LN

Term	Meaning
Enterprise Planning	The module holding LN's planning, both order-based and bucketed
Order planning	Planning recorded on a second by second basis, producing planned orders
Master planning	In LN this term means the optional bucketed tier only
Order method	The lot-sizing rule for a plan item
Order interval	The time window requirements are grouped into
Item master plan	The optional per-item bucketed plan, holding a supply plan by plan period
Order horizon	The period, in working days, that order based planning covers

Measurement

Term	Meaning
Fill rate	The share of demanded units served on the day they were required
Days of cover	Average stock held, divided by average daily demand
Balanced score	The mean of the categories rankable in a case, on a 0 to 100 scale within that case

1. Introduction

1.1 What the Module Does

Master planning, or MRP, answers one question on a schedule. Given what is on hand, what is already on order and what is expected to be demanded, what should be ordered and when. It runs nightly in most implementations, discards the previous set of proposals and rebuilds them from current data. It returns planned orders for a planner to review, together with messages proposing that existing orders be advanced, postponed or resized.

Read the entire future at full detail and the run returns thousands of proposals for orders that need no decision for months. Read only the near future and every item with a longer lead time than that window arrives late.

1.2 The Two Products

Dynamics 365 Finance and Operations is Microsoft's enterprise ERP. Master planning sits in its supply chain module, and the current engine, Planning Optimization, runs as a service outside the application. A coverage code sets the lot-sizing rule for an item. Time fences bound the horizon. F&O plans everything inside that horizon at daily resolution.

Infor LN is Infor's ERP for discrete manufacturing, where planning sits in Enterprise Planning. Every plan item is planned by order planning. Infor calls it "roughly comparable to traditional MRP planning". It records data "on a second-by-second basis" and produces planned orders.

An item may additionally carry an item master plan, "roughly comparable to traditional MPS planning". It records data "in terms of time buckets (plan periods)" and produces a supply plan by period instead of orders.

That second tier is a per-item choice and not the default. It is switched on by the Maintain Master Plan check box. Infor advises against it unless it is wanted, since item master plans "have an adverse effect on system performance. Therefore, you should only maintain an item master plan if you need specific master-plan functionality."

1.3 The Boundary

flowchart LR
    subgraph FO["Dynamics 365 F&O"]
        direction TB
        A1[Today] --> A3[Planned at full daily resolution<br/>coverage code sets the lot size]
        A3 --> A4{{Coverage time fence}}
        A4 --> A5[Demand here is not read.<br/>No requirement transaction.<br/>No message.]
    end
    subgraph LN["Infor LN"]
        direction TB
        B1[Today] --> B3[Order planning<br/>planned orders on exact dates,<br/>all materials and capacity]
        B3 --> B4{{Order horizon}}
        B4 --> B5{Maintain Master Plan<br/>set for this item?}
        B5 -- No --> B7[Planning horizon equals<br/>the order horizon.<br/>Nothing further is planned.]
        B5 -- Yes --> B6[Master planning<br/>supply plan by plan period,<br/>critical materials only,<br/>infinite capacity by default]
        B6 --> B8{{Planning horizon}}
    end

    classDef fine fill:#dcecdc,stroke:#3a7d3a,color:#0b0b0b
    classDef coarse fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef gone fill:#f6d8d4,stroke:#b0443a,color:#0b0b0b
    classDef bound fill:#ffffff,stroke:#52514e,color:#0b0b0b
    classDef dec fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b
    class A3,B3 fine
    class B6 coarse
    class A5,B7 gone
    class A4,B4,B8 bound
    class B5 dec

Figure 1. Colour marks the resolution demand is planned at. Green is full resolution, amber a bucketed plan, red a band that is not planned, blue a configuration choice.

The two differ at the boundary. F&O excludes the far horizon, and Microsoft states both the intent and the mechanism. The coverage time fence prevents "noise" caused by supply suggestions that don't require attention for months, and beyond it "the system doesn't generate requirement transactions for any supply and demand that falls outside the coverage time fence."

An LN item carrying a master plan lowers the resolution instead, in plan periods that may be short "for the immediate future and longer periods for longer-term planning". An LN item without one stops at its planning horizon, as F&O does.

2. Module Functionality

2.1 Lot Sizing

flowchart TD
    ROOT[Lot-sizing methods] --> B[Same mechanism in both products]
    ROOT --> F["Dynamics 365 F&O only"]
    ROOT --> L[Infor LN only]
    B --> B1["Requirement = Lot-for-Lot<br/>one order per requirement"]
    B --> B2["Period = Order interval<br/>a window that opens at demand;<br/>neither is anchored to the calendar"]
    B --> B3["Min./Max. = Replenish to Maximum<br/>refill when projected stock falls below a floor"]
    F --> F1[Priority-based replenishment]
    F --> F2[Decoupling point, DDMRP]
    L --> L1[Fixed Order Quantity]
    L --> L2[Economic Order Quantity]

    classDef both fill:#dcecdc,stroke:#3a7d3a,color:#0b0b0b
    classDef fno fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b
    classDef ln fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef root fill:#ffffff,stroke:#52514e,color:#0b0b0b
    class B,B1,B2,B3 both
    class F,F1,F2 fno
    class L,L1,L2 ln
    class ROOT root

Figure 2. Section 4 tests all five of these rules against each other.

Lot-sizing mechanism	Dynamics 365 F&O	Infor LN
One order per requirement	Requirement coverage code	Lot-for-Lot order method
Group demand in a floating window	Period coverage code. "The period starts with the first demand of the item"	Order interval, "measured starting at the last generated order"
Replenish to a maximum	Min./Max., triggered below a minimum	Replenish to Maximum Inventory, triggered below the inventory plan or safety stock
Fixed order quantity	No coverage code	Fixed Order Quantity order method
Economic order quantity	No coverage code	Economic Order Quantity, setting quantities "to at least the economic order quantity"
Priority-based replenishment	Priority coverage code	Not established
DDMRP decoupling buffers	Decoupling point coverage code	Not established. Allocation buffers are specification pegging, not DDMRP
Order multiple, minimum, maximum	Multiple, Min. and Max. order quantity on Default order settings	Order Quantity Increment, Minimum, Maximum
No automatic proposal	Manual coverage code	Order horizon of zero

Table 1. The first five rows are tested in Section 4.

2.2 Capabilities

Capability	Dynamics 365 F&O	Infor LN
Optional bucketed planning tier	None. One resolution across the horizon	An item master plan, per item, holding a supply plan by plan period
Plan periods of varying length	No equivalent	Shorter periods "for the immediate future and longer periods for longer-term planning". A period's quantity is spread across its days "proportional to the capacity on that day" rather than placed at a point
Far horizon beyond the boundary	Excluded from the calculation beyond the coverage time fence	No supply plan or planned order generated beyond the planning horizon
Capacity in the coarse tier	Not applicable	Infinite planning by default, taking no constraints into account. Workload control is the constrained alternative
Finite capacity scheduling	Supported	Order planning takes all necessary materials and capacity into account
Multi-level BOM explosion	Supported, including scrap, subcontracting, co-products and yield	Critical components only inside the master-planning horizon; all components once demand enters the order horizon
Safety stock	Minimum coverage, with pegging options per coverage group	Safety stock on the plan item, optionally with a seasonal pattern
Time fences	Coverage, freeze, capacity	Order horizon, planning horizon, forecast time fence and a time fence freezing the supply plan, all rounded to plan period ends
Exception and action messages	Action messages, futures messages, calculated delays	Exception messages by type, resource, planner and item
Simulation	Multiple master plans	Scenarios, one designated the actual scenario
Capable and available to promise	CTP supported from version 10.0.28	Standard ATP and component CTP without a master plan; ATP and CTP with one
Multi-site and intercompany	Forecast and downstream demand supported, cross-entity execution not yet	Planning clusters
Demand by sales channel	No direct equivalent	Channel master plans holding forecast, allowed demand and channel ATP
Return orders	Not considered by Planning Optimization	Not established. LN documents sales and purchase return orders, but no planning page connects them to Enterprise Planning

Table 2. Documented contrast.

Planning Optimization lists finite capacity scheduling, freeze time fences, auto firming, kanban, item substitution, subcontracting, co-products and formula yield as supported.

2.3 Documented Gaps in Planning Optimization

Not supported	Status per Microsoft
Return orders	"Planning Optimization doesn't consider return orders"
Freeze time fence set on item coverage	Pending, and currently ignored
BOM and formula lines with step consumption	Pending, and currently ignored
Sales line reservation using explosion	Future wave
Intercompany planning execution across legal entities	Future wave
Requirement types for skills, courses, certificates and titles	Future wave

Table 3. The whole of the documented gap, from the Planning Optimization fit analysis.

3. Data and Method

3.1 Sources

Every number in this article comes from two public files.

Demand comes from Online Retail II. It is the transaction file of a UK registered non-store online retailer selling giftware, largely to wholesale customers, published through the UCI Machine Learning Repository under CC BY 4.0. 1,067,371 rows, 1 December 2009 to 9 December 2011, across 5,131 stock codes. Each row is an invoice line carrying stock code, quantity, unit price and a timestamp. The row count matches the repository's own figure.

ONS series J596 is used for one check and does not enter the results. It is the Retail Sales Index for non-store retailing, value not seasonally adjusted. The seasonally adjusted version of the same series was downloaded and deliberately not used, since the check turns on whether the seasonal pattern matches.

Public demand history is rare. This is a distributor's order book, not a manufacturer's. Limits says what that rules out.

3.2 Filters Applied

Stock codes matching five digits with an optional letter suffix are retained. That excludes 61 non-item codes covering postage, adjustments, bank charges and samples. Credit invoices, and the 3,457 negative quantities outside them, are excluded from demand. An item enters the replay only with 12 or more demand days and a 180 day active window. That leaves 3,498 of the 4,773 items carrying any demand.

3.3 Classification

Items are classified on average demand interval and squared coefficient of variation of demand sizes, against cutoffs of 1.32 and 0.49 from Syntetos, Boylan and Croston. Those authors derived the cutoffs for selecting a forecasting method, not a lot-sizing rule. Measured weekly, the population divides into 120 smooth, 131 intermittent, 1,344 erratic and 1,903 lumpy items.

3.4 Constructed Inputs

Three inputs are constructed rather than observed.

Forecast error is generated, and Section 4.6 varies it. The five business cases are combinations of lead time, forecast error and item population, and no source claims they are typical. The opening stock, the tie margin and the remaining parameters are chosen values, listed in Limits.

3.5 Checks

One firm's order book should move with the national series for its sector. Against the ONS Retail Sales Index for non-store retailing, value not seasonally adjusted, the correlation over 23 complete overlapping months is 0.858 in levels and 0.807 in logs. Both series peak in November. The firm's November runs at 1.75 times its own yearly mean, the sector's at 1.35.

Structural check	What it asserts	What it catches
Wagner and Whitin bound	No lot-sizing rule may cost less than the exact optimum	A rule that reports a cost below the true optimum
Unit bucket identity	A one day window must equal one order per requirement	A window that groups demand it should not
Zero-noise identity	With a perfect forecast, a plan whose boundaries do not depend on demand must not move	An order timed off its release date
Reproducibility	A rerun in a fresh process must reproduce stored results exactly	A seed that is not stable across machines

Table 4. Each check is an identity rather than a plausibility test, so a defect cannot satisfy one by chance. All four hold for the published run.

3.6 Business Cases and Configurations

Case	Lead time	Forecast error	Items drawn from
Fast-moving distributor	5 days	10%	Smooth and erratic
Long-lead importer	60 days	20%	All classes
Spare parts operation	45 days	30%	Intermittent and lumpy
Seasonal wholesaler	20 days	20%	All classes
Volatile demand	14 days	40%	Erratic and lumpy

Table 5. Each case replans weekly over 104 runs, after a warm-up that is discarded. No coverage time fence is set in any of them.

Eleven configurations run in each case. Six are shared: one order per requirement, the floating window at 7, 14, 28 and 56 days, and replenish-to-maximum. Five are LN only: Fixed Order Quantity at 7 and 28 days of mean demand, and Economic Order Quantity at three setup-to-holding ratios. That ratio is a property of the business and is not in the data, so three values are swept.

The replenish-to-maximum minimum is set to cover the lead time. A minimum below the lead time cannot serve demand during replenishment.

Each configuration is scored on three outcomes, normalised from 0 to 100 against the best and worst achieved in that case. Service comes from fill rate, working capital from days of cover, planner workload from purchase orders raised per year. Scores are comparable within a case and not across cases.

4. Results

4.1 Service

Figure 3. The spread the eleven settings produce within each case, on a log scale. The service bars span all eleven, replenish-to-maximum included. Among the time-phased rules alone the spread is a fraction of a point, as the numbers below give.

Among the time-phased rules the fill rate spread is 0.00, 0.19 and 0.04 points in the three short lead time cases. It opens to 2.84 points at a 60 day lead time and 4.30 at 45 days with intermittent demand. Below those lead times the choice of rule is not a service decision.

Replenish-to-maximum is the exception. It served between 82.9 and 88.9 per cent across the five cases, where every time-phased rule served above 94 per cent. At short lead times it was dominated outright. In the fast-moving case it held 15.3 days of cover to serve 88.9 per cent, where a 7 day window held 5.5 days to serve 100. A reorder point cannot use forward visibility, and on this demand that costs more than it saves.

Wemmerlov reported the same in 1989: "when demands cannot be predicted, the choice of lot-sizing technique is not a very important issue", qualified to hold "when the procedures are applied under equal conditions, and when only holding and ordering costs are considered."

4.2 Scores by Business Case

Figure 4. Balanced score within each case. A solid box is a clear winner and a dashed pair is a tie. Orange labels mark the methods only LN documents.

Business case	Working capital	Planner workload	Balanced	Margin
Fast-moving distributor	One per requirement	56 day window	7 day window	0.50
Long-lead importer	Replenish to max	Replenish to max	56 day window	2.81
Spare parts operation	Replenish to max	56 day window	56 day window	9.93
Seasonal wholesaler	One per requirement	56 day window	7 day window	0.13
Volatile demand	One per requirement	56 day window	14 day window	1.02

Table 6. Margin is the gap between first and second. Anything under three points is reported as a tie.

The floating window, F&O's Period coverage code and LN's order interval, comes top in all five cases. Four of those are ties, at 0.50, 2.81, 0.13 and 1.02 points. The spare parts case separates, at 9.93.

The two methods only LN documents never placed better than third of eleven. Fixed Order Quantity reached third in three cases and fourth and fifth in the others. Economic Order Quantity placed lower again in every case. It took the service category in three cases, but only at the lowest setup-to-holding ratio tested. At that ratio it approaches one order per requirement and pays for the service in order count.

Two columns follow from the definitions rather than the results. The longest window wins planner workload because it raises the fewest orders. One order per requirement wins working capital because it holds the least stock. They are the two ends of one trade.

The right window length differs by business. 56 days for the two long lead time cases, 7 and 14 days for the three short ones.

4.3 Orders Against Stock

Figure 5. The floating window sits below and left of both LN-only methods at every length tested. At matched stock each raises more orders, and at matched order count each holds more stock.

Across the 795 item-configurations where both outcomes are defined, doubling the window changes purchase orders by −39.1 per cent and days of cover by +125.9 per cent. Simple theory predicts a halving and a doubling. Orders fall by less than half because demand at this granularity is lumpy, so many buckets sit empty.

Fixed order quantity and economic order quantity sit outside that trade at every setting tested. Economic order quantity sits further out than fixed order quantity. LN sets order quantities "to at least the economic order quantity", so it raises small requirements to the EOQ and leaves large ones alone. On lumpy demand that adds orders without removing stock.

4.4 Demand Classification and the Review Period

Review bucket	Smooth	Intermittent	Erratic	Lumpy
Daily	0.0%	4.5%	1.5%	94.0%
Weekly	3.4%	3.7%	38.4%	54.4%
Monthly	22.5%	2.7%	56.0%	18.7%

Table 7. The same 3,498 items in every row. Only the period the measurement was taken in changed.

Figure 6. The source paper defines the interval as "expressed in number of forecast review periods", so the measure carries the review period inside it.

Demand classifications are used to assign coverage codes. No item is smooth or lumpy on its own account. It is smooth or lumpy relative to a review period. Neither product names that period. The tool that produced the classification chose it.

4.5 Coverage Time Fence

Every setting above trades one outcome against another. The coverage time fence withholds demand from the calculation instead.

Figure 7. Four window lengths at a 60 day lead time. All four recover through the same fence. The dotted markers show where the transition would sit if the window length governed it.

Microsoft asks that the fence be "longer than the total lead time", and that rule is correct. Taking the 14 day window, a 60 day fence returned 89.6 per cent at a 60 day lead time, 65 days returned 94.9 per cent and 70 days returned 97.5 per cent against a plateau of about 98.1. Ten days above the lead time therefore recovers almost all of the loss. The replan cadence here is weekly, and the demand has to be visible for at least one run before the order is released.

The window length does not govern where service returns. Swept in five day steps at windows of 7, 14, 28 and 56 days, the four curves are indistinguishable through the transition, and the smallest fence within half a point of the best fill runs from 70 days at a 7 day window to 85 days at a 56 day window. Were the window length in control, those would fan out across the full 49 day span of the windows.

Across the 5,880 item-scenarios, each day the fence falls short of the lead time costs 0.451 percentage points of fill, at a robust t of −34.7.

4.6 Sensitivity to Forecast Error

Figure 8. Fill rate, order count and the order elasticity are drawn on scales wide enough to show movement and do not move. Plan stability, in red, moves across the whole range.

Forecast error is a parameter, not a property of the data. Its size was varied from 0 to 40 per cent and its persistence between runs across 0, 0.5 and 0.8. The three outcomes behind the scores held throughout. Fill stayed between 99.93 and 99.99 per cent, orders between 11.95 and 12.11 a year, and the order elasticity between −39.1 and −40.6 per cent.

One result moved in the direction the literature predicts. Days of cover rose from 11.73 to 14.33 across the sweep. Wemmerlov reports that forecast errors "not only lead to stockouts, they also induce larger inventories."

Plan stability was measured throughout. No claim is made from it. Counting a planned order as changed by a fixed number of units, and by a fixed percentage, point in opposite directions. That is a property of the measure and not of the products. Only the physical outcomes are reported.

5. Discussion

5.1 Where Demand Is Dropped

flowchart TD
    D[Demand line, due date D] --> Q{Is D within the<br/>coverage time fence?}
    Q -- No --> X[Not loaded into the engine.<br/>No requirement transaction.<br/>No message.]
    Q -- Yes --> C{Coverage code}
    C -- Requirement --> R[One planned order per requirement]
    C -- Period --> P[Window of L days opens<br/>at the first demand]
    C -- Min/Max --> M[Replenish to maximum<br/>when below minimum]
    R --> L{Is D minus lead time<br/>in the past?}
    P --> L
    M --> L
    L -- No --> OK[Planned order released on time]
    L -- Yes --> DEL[Delay. Order placed at the<br/>earliest feasible date]
    X -.-> LATE[Demand becomes visible only<br/>when it crosses the fence]
    LATE --> DEL

    classDef ok fill:#dcecdc,stroke:#3a7d3a,color:#0b0b0b
    classDef warn fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef gap fill:#f6d8d4,stroke:#b0443a,color:#0b0b0b
    classDef dec fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b
    class OK ok
    class DEL,LATE warn
    class X gap
    class Q,C,L dec

Figure 9. Blue is a decision the engine takes, green a demand served on time, amber one served late, red the path where the demand is never seen.

Observations from the diagram:

The red path raises nothing. No requirement transaction, so no action message, no futures message and no delay. The demand stays invisible until it crosses the fence.
The fence is measured from today, not from the item's lead time, and in calendar days. A week is seven days regardless of the working time calendar.
An item with a 60 day lead time behind a 30 day fence is a configuration no validation prevents.

5.2 Where the Fence Resolves

flowchart TD
    S[Master planning run starts] --> M{Coverage time fence<br/>set on the master plan?}
    M -- Yes --> MP[Master plan value wins.<br/>Item and group are ignored.]
    M -- No --> I{Override set on<br/>item coverage?}
    I -- Yes --> IC[Item coverage value wins]
    I -- No --> G{Set on the<br/>coverage group?}
    G -- Yes --> CG[Coverage group value wins]
    G -- No --> DF[Global default, 100 days]

    classDef win fill:#dcecdc,stroke:#3a7d3a,color:#0b0b0b
    classDef trap fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef dec fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b
    class IC,CG,DF win
    class MP trap
    class M,I,G dec

Figure 10. Amber marks the path that defeats an audit carried out at item level. Planning Optimization "first checks the item coverage line, then the coverage group, and finally the global coverage time fence", and a value on the master plan overrides all three. A review has to start at the master plan and work down.

5.3 Configuration

Find the exposure first. It is a report against setup tables and needs no transaction history.

For each item, resolve the coverage time fence the override chain returns, by working down Figure 10. The master plan wins if it carries a value, then item coverage, then the coverage group, then the 100 day default.
Compare that against the item's total lead time.
Every item whose fence does not clear its lead time is exposed. Rank them by lead time, longest first, since the loss grows with it.

Two settings decide the outcome. Both sit in the same two places.

Setting	Where	What to put in it
Coverage time fence	Master planning > Setup > Coverage > Coverage groups, General tab. Item coverage for a single item	Above the longest total lead time behind the group, with room to spare. Ten days above recovered almost all of the loss in these tests, and the 100 day default already clears every lead time tested here
Coverage period	The same two places	By business, not by policy. 56 days suited the spare parts case, 7 or 14 days the short lead time ones. One group-wide value across a mixed catalogue will be wrong for part of it

Set the fence first. Lengthening it trades nothing away, and the exposure is created by shortening it. The coverage period trades constantly, at 39 per cent of the orders against 126 per cent of the stock per doubling. That is a treasury decision, not a planning one.

Planning Optimization does not consider return orders. An expected return will not reduce a net requirement and the replenishment goes out regardless. Where return volumes are material, that stock has to reach the plan by another route.

Where a demand classification is used to assign coverage codes, record the review period it was measured in. Section 4.4 shows the class is not a property of the item alone.

5.4 For Microsoft

Request	Case for it	Evidence behind it
Validate the fence against the lead time	A fence shorter than the total lead time cannot serve the demand behind it, and the system already holds every number needed to say so	Measured. Section 4.5 prices the shortfall
Consider return orders in the planning calculation	A documented gap with a direct operational consequence	Microsoft's own fit analysis
A coarse far horizon	Seeing a long lead time item's far demand today means admitting it at full daily resolution. That is the noise the fence exists to suppress	None

The first costs little and the evidence is in Section 4.5. The second is Microsoft's own documented gap rather than an inference from anything here.

The third carries no measurement. LN's optional item master plan puts a coarse plan beyond the order horizon where F&O has nothing. Its purpose is visibility, not replenishment, so replaying independent demand cannot price it. Infor advises against maintaining it unless the functionality is wanted.

Fixed Order Quantity and Economic Order Quantity should not be requested. On this demand neither improved on the coverage codes F&O already ships.

5.5 What the Analysis Supports

Claim	Where it comes from
The floating window tops every business case, and the two LN-only methods never place better than third	Data
Four of five cases are ties. The one that separates goes to a shared setting	Data
Doubling the window costs 39 per cent of orders and adds 126 per cent to stock	Data
Service barely separates time-phased rules below a 45 day lead time	Data
A fence short of the lead time costs 0.451 points of fill per day	Data
The demand classification moves with the review period it is measured in	Data
Which lot-sizing rules each product offers	Documentation
That LN's second tier is optional, and Infor advises against it by default	Documentation
Everything in Table 2	Documentation

Table 8. Six findings from the data. The rest from the two vendors' published manuals.

Neither an LN nor an F&O system was run in this modelling exercise. Both sets of rules were reimplemented from documentation. Therefore a behaviour that differs from the documentation is invisible to this method. Where Infor's manuals are silent, the assumption made is recorded in the repository.

Limits

This is one wholesaler's order book, with no bills of material, routings or capacity. Nothing here tests dependent demand, multi-level netting or capacity scheduling. That bounds the findings to purchasing and distribution. The lot-sizing literature places uncapacitated results there too. Wemmerlov notes that such work is "applicable to purchasing/distribution situations but not necessarily to decisions related to manufacturing lot sizes." The fence result is derived at a single level, and a multi-level bill would extend the requirement.

No safety stock was modelled. F&O's minimum coverage is a standard setting any implementation carrying a 60 day lead time would use, so the fence results are the cost of the exclusion with nothing buffering it, and the magnitudes are an upper bound. The direction of the omission is known. Introducing safety stocks "generates even larger inventories and also more orders", so both the stock and the order counts reported here would rise.

Forecast error is the assumption the plan stability results rest on. Section 4.6 reports the range they move across. No stability figure here should be read as a prediction for a live system.

The structural checks cover the lot-sizing rules and not the whole replay, since the Wagner and Whitin bound applies to the rules alone. The fine sweep behind Figure 7 sits at a single 60 day lead time. The 0.451 point per day figure spans lead times of 5, 15, 30, 45, 60, 75 and 90 days against seven fences. The ten day recovery margin is close to the seven day replan cadence used throughout, so a different cadence would move it.

The balanced score is the mean of the categories rankable in a case. It weights them equally, and that weighting is a judgement. Table 6 carries the per-category winners alongside it.

Chosen parameters. Each moves some conclusion if moved. The 1.32 and 0.49 cutoffs, the weekly review period behind the classification, the activity filter of 12 demand days and a 180 day active window, the 28 day visibility window, the weekly replan cadence, opening stock of 14 days, the warm-up period, the three point tie margin, the minimum spreads for ranking a category, and the setup-to-holding ratios swept for economic order quantity.

No organisation is accused of anything. The wholesaler is not named in the source and is not identified here. Neither Microsoft nor Infor is alleged to have documented anything incorrectly.

Reproducing This

The source code and datasets are at github.com/kingomnivore/mrp-fno-vs-ln. Clone it, pip install -r requirements.txt, then python run.py. Both data files are committed, the workbook through Git LFS, so it runs as cloned.

The recipe below describes the same analysis independently of the code, for anyone who would rather rebuild it.

1. Get the data. Online Retail II from the UCI Machine Learning Repository, both sheets of the workbook. ONS series J596, value not seasonally adjusted, for the check in Section 3.5 only.

2. Aggregate. Reduce the order lines to daily demand per item. Drop non-item codes, credit lines and negative quantities, then apply the activity filter in Section 3.2.

3. Classify. Compute the demand interval and the squared coefficient of variation of demand sizes in the review period the business intends to plan in, and split on 1.32 and 0.49.

4. Implement the rules. Code the lot-sizing rules from both vendors' documentation, including the ones the product under test does not offer, giving each rule the same treatment where the documentation is silent.

5. Replay. Define business cases as combinations of lead time, forecast error and item population. Run every rule in every case, replanning weekly, and commit each order on its release date rather than its receipt date.

6. Score. Discard the warm-up. Score each category only where the underlying outcome differs across configurations, and report the margin alongside the rank.

7. Sweep. Vary the forecast error before reporting anything that depends on it.

8. Check. Run the four identities in Table 4 before reading any result.

Chosen parameters. As named in Limits.

On Method

Sources

Dynamics 365 Supply Chain Management documentation

Infor LN Enterprise Planning documentation

Master planning versus order planning
Master planning, an overview
Demand and Inventory Planning
Infor LN Enterprise Planning, User Guide for Order Planning. Source for the order interval, the order methods and the plan period distribution rules
Plan periods in Enterprise Planning
Order interval
Items - Planning (cprpd1100m000)
Order horizon
Allocation buffers
Glossary for Enterprise Planning
Analysis code and data, GitHub

About Author

Dean Fachrie is a Functional Analyst at CodeCore Dynamics LLC, working on Microsoft Dynamics 365 F&O architecture and enterprise system design.

Configuring master planning, or evaluating Dynamics 365 F&O against another ERP?

We help enterprise supply chain and finance teams set coverage codes and time fences so master planning reads the whole horizon it should, and size replenishment against the working capital the business will carry.

Airline invoicing in D365 F&O

Dean Fachrie — Mon, 31 Aug 2026 18:23:23 +0000

The purchase order price source determines what an invoice match verifies.

CodeCore Dynamics LLC. Edited 9 September 2026.

Summary

F&O matching compares an invoice to its own purchase order. The control is therefore not stronger than its source.
A price from a trade agreement was fixed before the transaction and applies across all of them. Where a buyer typed the price onto the PO, matching checks the vendor against their own quote. Both produce the same match status.
Two years of US airline filings show fuel pricing within 4 per cent of its own agreed rate, while airframe repair spans 32 per cent. Fuel can be driven from master data. Repair cannot.
The same charge measured against a different benchmark can flip the verdict. Fuel varies by 16 per cent against the industry and 4 per cent against its own indexed rate, either side of the 15 per cent line for automating.
The legal entity price tolerance defaults to 0 per cent, and that default record cannot be deleted.
Charges matching requires both Match charges at legal entity level and Compare purchase order and invoice values on the individual charges code.
At a 10 per cent tolerance a repair charge sends roughly a third of its invoices for manual review, against one in ten for fuel.

For finance leadership

The current position can be established without opening the system. Ask what the legal entity price tolerance is set to. If it remains at 0 per cent, every price variance is being flagged. Ask which charges codes have Compare purchase order and invoice values selected. The codes without it post unchecked and raise no error. And finally, ask what share of purchase order lines take their price from a trade agreement rather than from manual entry. That share is the exposure this article describes.

The running cost is in Section 4.4. At a 10 per cent tolerance, repair flags 31 per cent of its invoices against 10 per cent for fuel. This reflects three times the review time, and the reviewer has no agreed price to compare against.

Where no rate exists, a price tolerance creates review load and checks nothing. Quantity matching does not depend on a rate and should stay on.

Terms

Dynamics 365 F&O

Term	Meaning
Purchase order (PO)	The order raised before the goods or services arrive, carrying an agreed price, quantity and any charges
Product receipt	The record of what was received
Net unit price	The net amount of a line divided by its quantity
Two-way matching	Compares the net unit price on the invoice line to the net unit price on the PO line
Three-way matching	Two-way matching plus invoice quantity against the quantity on the matched product receipt
Line matching policy	Which of the above applies. Set for the legal entity and overridable by vendor, item, or item and vendor
Price tolerance	The variance allowed before a discrepancy is reported
Invoice totals matching	Compares totals on the invoice to the totals expected from the PO
Trade agreement	Stored agreed prices per vendor and item, used to populate the PO price
Purchase agreement	A commitment to buy an agreed volume or value, carrying agreed pricing
Charges code	A named cost added to an order or invoice, such as freight, handling or a landing fee
Charges matching	Compares charge amounts on the invoice to charge amounts on the PO
Legal entity	The company the configuration belongs to
Rung	Used in this article for where a PO price came from, per Table 1. Not a Microsoft term.

Aviation

Term	Meaning
Flight hour	Time the aircraft is airborne. The driver for maintenance and crew cost
Capacity purchase agreement	A mainline carrier pays a regional to operate routes on its behalf, commonly supplying the fuel
ACMI	A lease where the operator supplies aircraft, crew, maintenance and insurance, and the customer covers fuel
14 CFR Part 241	The US regulation requiring carriers to file the financial schedules used here

1. Introduction

Two-way matching in Dynamics 365 F&O compares the net unit price on the invoice line to the net unit price on the purchase order line. Three-way matching additionally compares the invoice quantity to the quantity on the matched product receipt.

Both comparisons take the purchase order as the reference. That reference came from somewhere, and where it came from determines what a passed match establishes. F&O does not distinguish between those sources anywhere in the interface.

Rung	Source of the PO price	Passed match means
1	Trade agreement or purchase agreement	The vendor billed a price set outside the transaction
2	A quote entered onto the PO by a buyer	The vendor billed the amount they quoted
3	A line added at invoice entry, with no PO line	Line matching does not apply

Table 1. The same match status is produced at every rung.

Rung 2 confirms the vendor has not deviated from their own quote. It carries no information about whether the quote was reasonable.

Reaching rung 1 requires a rate stable enough to hold in master data. Sections 2 to 4 test which charges have one using public airline financial filings. Section 5 sets out what follows for the F&O configuration.

2. Dataset and cleaning

2.1 Source

BTS Form 41 Schedule P-5.2, quarterly aircraft operating expenses, 2024 and 2025. The dataset contains 4,805 rows across 47 carriers, 95 aircraft types and 8 quarters. Each row conforms to a matched carrier, aircraft type, and quarter.

Airlines are one of the few industries where third-party spend and the quantity driving it are both public. US carriers file both under 14 CFR Part 241. The same analysis is not possible from public data at a manufacturer.

The code, the filings and the raw output are in a public repository, linked below.

2.2 Charges selected

Charge	Amount field	Account	Driver field
Aircraft fuel	`FUEL_FLY_OPS`	51451	`AIR_FUELS_ISSUED`
Engine repair	`ENGINE_REPAIRS`	52432	`TOTAL_AIR_HOURS`
Airframe repair	`AIRFRAME_REPAIR`	52431	`TOTAL_AIR_HOURS`
Pilot pay	`PILOT_FLY_OPS`	51230	`TOTAL_AIR_HOURS`

Table 2. The first three are third-party spend arriving as vendor invoices. Pilot pay is account 51230 (salaries), not meeting invoice matching. It is carried through the figures as a rate that is contracted but not invoiced.

2.3 Units

Amounts are reported in thousands of dollars and quantities in thousands. Therefore, amount divided by driver yields dollars per gallon and dollars per flight hour.

Two independent checks:

The fuel rate resolves to $2.43 per gallon. US Gulf Coast kerosene-type jet fuel spot averaged $2.23 over the same 24 months. The filed figure therefore sits about 9 per cent above the spot benchmark. This is the correct direction and a plausible magnitude where account 51451 is delivered cost, carrying the supplier differential, the into-plane fee and taxes on top of spot. In contrast, a figure below spot, or one several times it, would indicate a units error.

Pilot pay resolves to $1,498 per flight hour, which falls in the published range for narrowbody crew cost per block hour. The two checks are independent of each other.

2.4 Filters applied

Rows below $100,000 of quarterly spend are excluded, since rounding in the filing dominates the implied rate at that scale. A carrier and aircraft type requires at least four quarters on file before it is treated as having an established rate of its own. After filtering, fuel retains 2,175 rows across 143 carrier and aircraft combinations.

2.5 A mixed population in the fuel data

132 fuel rows, 6.1 per cent of the file, imply a rate below $1.00 per gallon. These are regional carriers operating capacity purchase agreements and ACMI cargo operators, which burn fuel a partner pays for, so gallons are reported against little or no cost. The carriers concerned are SkyWest, Republic, Atlas Air and ABX Air. This is a commercial arrangement, not a reporting error. The rows are retained.

The effect on each measure differs, as the table below shows.

Fuel	n	Median rate	Pooled R²	Within band	Variance
As published	2,175	$2.43	0.922	0.689	0.039
Excluding under $1.00/gal	2,043	$2.45	0.986	0.862	0.036

Table 3. R² shifts substantially, whereas the median rate and variance remain largely unchanged.

A measure built on medians tolerates a mixed population. One built on squared deviations does not. In accounts payable, applying a single tolerance at vendor group level may fail when one charge code covers multiple pricing structures.

3. Analysis

Two measures are computed for each charge.

Measurement

Term	Meaning
Driver	The quantity determining the amount. Gallons for fuel, flight hours for repair
Unit rate	Amount divided by driver. Dollars per gallon, dollars per flight hour
Benchmark	The reference a unit rate is compared against. Check 3.2 for defined benchmarks
R²	The share of variation in the amount explained by the driver, from 0 to 1
Median	The middle observation of data
Interquartile range (IQR)	The span covering the 25th to the 75th per centile
Variance	IQR divided by the median. A value of 0.04 means the middle half sit within 4 per cent of the benchmark. In this article, this is a measure of dispersion.

The measurement terms used from here on.

3.1 Drivers

An ordinary least squares fit of amount = a + b × driver, reported as R².

Pooled R² is inflated in this dataset because carrier size correlates with both variables independently of any pricing discipline. The fit is therefore repeated within driver size quartiles and averaged, which removes most of that effect.

3.2 Unit Rate

The amount divided by the quantity gives the unit rate. A variance value of 0.04 indicates that the middle half of observations price within 4 per cent of their benchmark.

A charge is treated here as worth automating where that variance falls below 0.15. The threshold is a judgement and not a derived value, and is named again in Limits. Variance is reported as a decimal in the tables that follow.

The benchmarks chosen for this model:

Industry. A single rate across all carriers.
Indexed. The median rate within the same quarter, removing market movement.
Own rate. The carrier's own median, without market movement.

In purchase agreement terms, these correspond to no agreement, an index-linked agreement, and a vendor-specific trade agreement.

4. Results

4.1 Driver explanatory power

Charge	Pooled R²	Within size band
Aircraft fuel	0.92	0.69
Engine repair	0.51	0.13
Airframe repair	0.43	0.11

Table 4. Gallons account for most of the variation in fuel spend. Flight hours account for little of the variation in repair spend.

Figure 1. The fuel relationship is close to linear. The repair relationship is dispersed.

4.2 Rate variance

Charge	Unit rate	Variance against own rate
Aircraft fuel	$2.43 / gallon	0.04
Engine repair	$334 / flight hour	0.23
Airframe repair	$285 / flight hour	0.32

Table 5. An eightfold difference between fuel and airframe repair, on identical carriers, aircraft and quarters.

Figure 2. Each invoice divided by its own benchmark. The variance in Table 5 is the width of these distributions expressed as one number.

4.3 Effect of benchmark choice

Charge	vs industry	vs same quarter	vs own rate
Aircraft fuel	0.16	0.08	0.04
Engine repair	1.20	1.14	0.23
Airframe repair	1.27	1.20	0.32

Table 6. Read across rows.

Figure 3. Fuel variance falls below the 0.15 threshold only once the benchmark accounts for the quarter.

Indexing reduces fuel variance from 0.16 to 0.08, and vendor-specific pricing reduces it again to 0.04. Indexing therefore accounts for half of the total improvement. For repair, all three benchmarks remain wide.

4.4 Review load

A tolerance flags every line whose deviation from its benchmark exceeds it, so the share flagged is the workload the control creates. That share differs by charge as sharply as the variance.

Charge	5%	10%	15%	25%
Aircraft fuel	13%	10%	9%	6%
Engine repair	31%	26%	23%	18%
Airframe repair	38%	31%	26%	17%

Table 7. Share of invoices sent for manual review at each price tolerance, measured against the benchmark that holds each charge tightest.

Figure 4. At every tolerance, the repair charges flag two to three times as many invoices as fuel.

At a 10 per cent tolerance fuel sends one invoice in ten for review, whereas airframe repair sends close to one in three. Section 4.2 shows there is no stable rate for that review to check against.

5. Discussion

5.1 The path an amount takes

flowchart TD
    TA["Trade agreement or<br/>purchase agreement"]
    QUOTE["Buyer enters a quote<br/>onto the PO"]
    ADDED["Line added at invoice entry,<br/>not on the PO"]

    PO["Purchase order line<br/>price, quantity, charges"]
    RCPT["Product receipt"]
    INV["Vendor invoice"]

    LMP{"Line matching policy"}
    PRICE["Price check<br/>net unit price, price totals"]
    QTY["Quantity check<br/>vs received quantity"]
    NOLINE["No line matching"]

    MCH{"Match charges<br/>legal entity"}
    CTOG{"Charges code:<br/>Compare PO and invoice values"}
    CCHK["Charges check<br/>vs Charges tolerances"]
    CGAP["Charge not matched"]

    TTOG{"Match invoice totals<br/>legal entity"}
    TCHK["Invoice totals check"]
    TGAP["Line not matched"]

    LEDGER["Posted to the ledger"]

    TA -->|rung 1| PO
    QUOTE -->|rung 2| PO

    PO --> LMP
    RCPT --> LMP
    INV --> LMP
    LMP -->|two-way or three-way| PRICE
    LMP -->|three-way only| QTY
    LMP -->|not required| NOLINE

    PO --> MCH
    MCH -->|on| CTOG
    MCH -->|off| CGAP
    CTOG -->|selected| CCHK
    CTOG -->|not selected| CGAP

    ADDED -->|rung 3| TTOG
    TTOG -->|on| TCHK
    TTOG -->|off| TGAP

    PRICE --> LEDGER
    QTY --> LEDGER
    NOLINE --> LEDGER
    CCHK --> LEDGER
    CGAP --> LEDGER
    TCHK --> LEDGER
    TGAP --> LEDGER

    classDef strong fill:#dcecdc,stroke:#3a7d3a,color:#0b0b0b
    classDef weak fill:#fbe8cd,stroke:#b8761c,color:#0b0b0b
    classDef gap fill:#f6d8d4,stroke:#b0443a,color:#0b0b0b
    classDef check fill:#e8eef6,stroke:#2a78d6,color:#0b0b0b

    class TA strong
    class QUOTE,ADDED weak
    class NOLINE,CGAP,TGAP gap
    class PRICE,CCHK,TCHK check
    class QTY strong

Figure 5. Colour represents the strength of the reference behind each check, blue marking the checks and red the paths where no check happens.

Charges codes appear on the purchase order, and charges matching compares the invoice charge to the PO charge. A line added at invoice entry that was not on the purchase order, falls outside line matching and is covered by invoice totals matching only.

Observations from the diagram:

Price check strength derives from the source. The comparison is identical whether the PO price originates from a trade agreement or from manual buyer entry, producing the same match status in both cases.
Quantity check strength derives from the product receipt.Invoiced quantity and received quantity are both recorded values rather than judgements, so the check needs no rate, no tolerance and no master data. It runs under a three-way policy only.
Three branches reach the ledger without a line-level comparison: a PO line under a Not required matching policy, a charges code with Compare purchase order and invoice values not selected (or Match charges off at legal entity level), and an invoice-entry line with Match invoice totals off.

5.2 Configuration

Fuel belongs on rung 1. Its rate holds to 0.04 against a vendor-specific indexed benchmark, which is stable enough to sit in a purchase agreement. Since half the available improvement comes from indexing to the period rather than from vendor-specific pricing, the agreement would benefit from a refresh process tied to the index.

Repair remains on rung 2. No benchmark brings its variance near 0.15, so no stable rate exists to place in master data. Each PO price will be a per-event quote, and matching will do no more than confirm it, at the review cost shown in section 4.4. That limitation belongs to the charge instead of the configuration.

Quantity matching does not depend on the rung. Set Line matching policy to Three-way match on Accounts payable > Setup > Accounts payable parameters, on the Invoice validation tab, together with Enable invoice matching validation, wherever a product receipt is taken.

Price tolerances. Set on Accounts payable > Setup > Invoice matching setup > Price tolerances, resolving from item and vendor down to All/All. The legal entity default is 0 per cent and cannot be deleted, so any price variance is reported until a tolerance is entered. Override the matching policy per vendor or item on Accounts payable > Setup > Invoice matching setup > Matching policy, which resolves item and vendor, then item, then vendor, then legal entity.

Charges. Enable Match charges in Accounts payable parameters and set the Charges tolerances page. Charges matching runs only on charges codes where Compare purchase order and invoice values is selected on the Charges code page.

Duplicate invoice numbers. The Check the invoice number used parameter in Accounts payable parameters, set to Reject duplicate or Reject duplicates within fiscal year, applies independently of any rate.

5.3 What the analysis supports

The analysis establishes which charges can be driven from master data and how a fuel agreement should be structured. Everything else in section 5.2 comes from the product documentation, and the rung model in section 1 follows from how matching is defined.

Price protection in F&O grows with the quality of the master data behind the purchase order, whereas quantity protection is independent of it. Where no stable rate can be established such as in section 4 for engine and airframe repair, the constraint is commercial and no configuration will be able to remove it.

Limits

The filings are quarterly aggregates rather than individual invoices. A quarter combines many transactions, so part of the reported variance reflects differences in work mix rather than pricing. The ordering between charges is the result. The absolute values are not tolerance settings.

Three parameters are judgement rather than derived: the $100,000 minimum row, the four-quarter minimum history, and the 0.15 variance threshold marked on Figure 3.

No evidence of overcharging at any carrier is presented, and no carrier is identified as such. The analysis addresses which charges can be checked, not what any operator would recover.

Configuration detail is taken from Microsoft Learn and has not been verified against a specific implementation. Version differences apply.

Reproducing this

The source codes and datasets are at github.com/kingomnivore/airline-invoices-dynamics365-fno. Clone it, pip install -r requirements.txt, then python run.py. The filings are committed, so it should run as cloned.

The recipe below describes the same analysis independently of the code, for anyone who would rather rebuild it. It is a download, 4 filters and 2 ratios, without the modelling.

1. Get the data. From TranStats, Air Carrier Financial, Schedule P-5.2, select all fields, set Quarter to All Quarters, and download 2024 and 2025. Concatenate them. The amount and driver columns for each charge are in Table 2.

2. Filter. Keep rows where the amount exceeds 100 and the driver exceeds 0. Amounts are in thousands. Keep only carrier and aircraft type combinations with at least four quarters on file.

3. Unit rate. Divide amount by driver. Both columns carry the same factor of a thousand, so the result is dollars per gallon and dollars per flight hour directly.

4. Explanatory power. Fit amount = a + b x driver by ordinary least squares and take R2. Then split the rows into quartiles by driver, refit inside each, and average those. The second figure is the one to report, since carrier size inflates the first.

5. The benchmarks. Each is the unit rate divided by a reference.

Benchmark	Reference
Industry	The median rate across all rows
Indexed	The median rate within the same year and quarter
Own rate	The indexed deviation divided by its own median within each carrier and aircraft type

6. Variance. For each set of deviations, take the 75th per centile minus the 25th, divided by the median.

7. Check. The fuel median should be $2.43 per gallon and pilot pay roughly $1,498 per flight hour. The two are independent, check if either are off the column for units.

Chosen parameters. The $100,000 floor, the four-quarter minimum, and the 0.15 threshold drawn on Figure 3 were deliberate choices assumed.

On method

Sources

About Author

Dean Fachrie is a Functional Analyst at CodeCore Dynamics LLC, working on Microsoft Dynamics 365 F&O architecture and enterprise system design.

Working on a complex F&O implementation or evaluation?

We help enterprise finance teams design clean, automated procurement and invoice-matching workflows.