SAP Data Load Sequence: Master, Balances, Open Items

Decision context

Load order is not a preference. It is a dependency graph, and the dependencies are mostly obvious in retrospect and mostly discovered at the wrong time: a document that references a customer that is not there, a balance posted to an account that does not exist, an open item in a currency the target does not know.

The general shape is stable across programs. Configuration and organisational structure first, then master data in its own dependency order, then opening balances, then open items and open documents, then anything that depends on those.

The part that matters as much as the order is where the reconciliation checkpoints sit. Reconciling once at the end tells you a number is wrong. Reconciling after each layer tells you which load produced it.

Layer 1: configuration and organisational structure

This is normally transported rather than migrated, but nothing loads correctly without it, so it belongs in the sequence.

• Company codes, controlling areas, plants, sales and purchasing organisations, storage locations, and the assignments between them.
• Chart of accounts and account determination, before any financial object is loaded.
• Number ranges for every object being loaded, including whether the load supplies the number or the system assigns it.
• Currencies, exchange rate types and rates, units of measure, and language keys that the data will reference.
• In S/4HANA, the customer and vendor integration setup has to be in place before business partners are loaded, or the load produces partners that do not carry the roles the process needs.

Layer 2: master data, in dependency order

Master data has its own internal order. The rule is that anything referenced by another object goes first.

• General ledger master, cost elements, cost centers, profit centers, and internal orders.
• Business partners with their customer and supplier roles, including the bank data and the partner functions the process needs.
• Materials, with the views required by each plant and organisational level, followed by anything that references them.
• Bills of material, routings, work centers, and production versions where in scope, since each references the material and the previous object.
• Pricing conditions, output conditions, tax codes, and output determination, all of which reference partners or materials.
• Assets master, which references the asset classes and the accounts from layer 1.
• Reconciliation checkpoint: record counts per object and per organisational unit, and a completeness check against the source extract rather than against the file that was uploaded.

Layer 3: balances, then open items

This is where a migration is most often judged, because the numbers are the ones the business already knows. Order and reconciliation both matter here more than anywhere else.

• Asset balances, including acquisition values and accumulated depreciation, which have to reconcile to the general ledger accounts they belong to.
• Inventory, using the initial stock movement, valued so that the resulting stock account balance is known before the general ledger balances are loaded.
• General ledger opening balances, posted against a migration offset account so the load is self-balancing and the offset can be proved to net to zero.
• Accounts receivable and accounts payable open items, which post to the subledger and must reconcile to the corresponding reconciliation account balance.
• Reconciliation checkpoint after each of these, not once at the end: subledger to general ledger, asset subledger to accounts, stock value to the stock account, and the migration offset account to zero.
• Open items must carry the correct document date, posting date, baseline date, and payment terms, or the aging report will be wrong on day one even though the balance is right.

Layer 4: open transactional documents

These reference everything above and are the layer where a missing master record surfaces as a wall of identical errors.

• Open purchase orders and scheduling agreements, with their delivery and invoice status representing the real remaining commitment.
• Open sales orders and contracts, with the same requirement on partial delivery and billing status.
• Open production and process orders where in scope, with their component reservations and confirmations.
• Open deliveries and anything in transit, which is frequently the messiest category and the one most often reduced by agreeing a business freeze rather than migrating it.
• Reconciliation checkpoint: open commitment values and open order quantities compared against the source, by organisational unit.

What the workflow must cover

• Dependency-derived order. Build the load sequence from the references between objects rather than from the order the data owners delivered their files.
• Checkpoint placement. Place a reconciliation checkpoint after each layer so a variance is attributed to the load that produced it.
• Self-balancing loads. Keep financial loads self-balancing through a migration offset account whose residual can be proved to be zero.
• Cutover timing. Carry measured per-object load durations into the cutover downtime budget.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Confirm configuration and organisational structure are complete in the target.
2. Load master data in dependency order with a completeness check per object.
3. Load asset balances, inventory, general ledger balances, then open items.
4. Reconcile at each checkpoint before starting the next layer.
5. Load open documents and reconcile open commitments and quantities.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Configuration completeness confirmation
• Per-object record counts
• Source extract completeness check
• Subledger to general ledger reconciliation
• Stock value to account reconciliation
• Migration offset account residual
• Open commitment comparison
• Per-object load runtime

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• Scope decides the sequence. An implementation without production planning or asset accounting has a shorter chain, and copying a full sequence into a narrow scope wastes a cycle.
• Open document migration is often reduced by a business freeze, and that is a business decision rather than a technical one.
• Reconciliation proves the totals moved. It does not prove the data is fit for the process, which is what integration and acceptance testing are for.

Buyer checklist

• Is the load order derived from references or from file availability?
• Does the migration offset account net to zero?
• Does every subledger reconcile to its reconciliation account?
• Do open items carry the dates that drive aging?
• Which open document categories were excluded by the business freeze?