SAP Batch Input: SM35 guide and 7 production pitfalls

On recent S/4HANA projects, you still regularly hear that batch input “is a thing of the past, we only use LTMC now”. The claim is convenient, it makes life easier for a project manager who wants to lock down a single migration standard. The trouble is, it is wrong. Batch input has not disappeared, it has changed its role. In 2026, it is no longer the initial load tool (Migration Cockpit has taken that place), but it remains the tactical weapon you reach for when a custom Z transaction, a mass correction in production, or a legacy BDC script refuses to die. This article positions it for what it is today: not the primary method, but a niche tool you still cannot do without.

How a batch input works under the hood

Batch input relies on a mechanism named BDC, for Batch Data Communication. The idea is simple. You record what a user would do on screen (selecting a menu, entering a field, confirming), you structure that sequence in a system table, and you have the system replay the whole thing as if it were a human entry. SAP does not cut corners on the checks. Every replayed screen goes through the same consistency validations as a manual entry. This explains both the reliability of the method and its relative slowness.

Concretely, a batch input session is an object stored in two main tables. APQI contains the session header (name, status, creator, number of transactions). APQD stores the data screen by screen through the ABAP structure BDCDATA. Two other tables work behind the scenes: APQL for locking and APQO for sessions currently running. None of these tables should ever be modified directly. They are driven by the function modules BDC_OPEN_GROUP, BDC_INSERT, and BDC_CLOSE_GROUP.

The transaction SM35 is the console that lets you view, analyze, and restart these sessions. Its main screen lists every session in the system with its status: New (created, not yet processed), Run (running), Error (at least one record failed), Keep (finished but kept for analysis), Read (read-only).

The official reference documentation is SAP Note 36677, which details the known limitations and best practices going back to the ECC era. It is still cited in more recent notes related to S/4HANA, which says a lot about the longevity of the mechanism.

Batch input vs LSMW vs Migration Cockpit LTMC vs BAPI vs OData: when to choose what in 2026

On a recent S/4HANA project, the choice of load tool is no longer made the way it was in 2015. Migration Cockpit (LTMC), officially available since S/4HANA 1610, has taken the place that LSMW once held. Yet no single tool covers every need. Here is the decision grid I apply on my projects.

The implicit rule: if a BAPI or an OData service exists and covers your business object, use it without hesitation. You gain in performance, in ABAP readability, and in stability against version changes. Batch input only comes back into the conversation once these options have been ruled out.

The 3 SM35 execution modes and the criteria for choosing

When you launch a batch input session from SM35, SAP offers three execution modes. The choice is not cosmetic. It determines both the processing time and the amount of human attention required.

My reflex on assignments: I always test in Process foreground on three or four randomly picked records before launching in Background. Five minutes spent stepping through is cheaper than several hours debugging a corrupted session afterwards.

Building a batch input session cleanly

The classic entry point for generating a batch input session is SHDB (Transaction Recorder). You start the recording, run through the transaction you want to industrialize, stop it, and the system produces two deliverables: the filled BDCDATA structure, and a reusable ABAP skeleton that calls BDC_OPEN_GROUP, loops over the data with BDC_INSERT, and closes with BDC_CLOSE_GROUP.

Three technical precautions make the difference between a script that survives in production and one that breaks at the first transport:

1. Stabilize the entry screen before recording. If the transaction has screen variants or optional custom fields, lock them down through SHD0 and transaction variants before launching SHDB. A session recorded on a configurable screen breaks as soon as the configuration changes.
2. Always populate BDC_OKCODE, BDC_CURSOR, and BDC_DYNPRO. These three special fields drive, respectively, the action code (confirm, back), the cursor position, and the screen number. Forgetting them causes random behavior depending on the execution context.
3. Test on three data sets that cover the tricky cases. A nominal case, a case with empty optional fields, a case with warning messages. That is enough to flush out most bugs before the mass session.

The ABAP skeleton generated by SHDB is deliberately basic. It is up to you to add the reading of the source file (CSV, staging table, selection on a business table), line-by-line error handling, and logging in the format your support team uses. Never ship a batch input program without a structured error handler.

The 7 pitfalls that blow up a batch input in production

Here are the seven cases I have seen break batch input sessions on my assignments. None of them is exotic. All of them are predictable if you know what to look for.

1. Lock conflict on master data. If a user is editing the material or the customer account in question, the session blocks. A prior check through SM12 or a mandatory overnight run window is required.
2. Transporting the program without transporting the session. Sessions live in APQI/APQD and are not natively transportable. The program is. As a result: you transport the code to production, then recreate the session on the target environment.
3. Session of more than 50,000 records. Beyond that, the lock time on certain system tables becomes critical. Split into sessions of 5,000 to 10,000 records maximum.
4. Modal screen not anticipated during recording. A confirmation popup, a warning message to dismiss, and the whole session goes off the rails. A mandatory test in Display errors only on a sample before production.
5. Dependency on the SAP GUI version or theme. If the execution user has a different GUI from the creator, some fields may not exist. Always run under a technical user with a standardized profile.
6. Custom Z fields added after the recording. Developers like to add fields on custom screens. If the field appeared after the SHDB, the session does not fill it, and the transaction goes into error as soon as it is mandatory.
7. Local date and number formats. A session recorded by a FR user with the format DD.MM.YYYY crashes for an EN user with the format MM/DD/YYYY. Force the execution user parameters explicitly in the program.

If a session fails partially, never restart the whole thing. SM35 offers a “Reprocess errors only” option that replays only the records in Incorrect status. Otherwise you risk duplicates.

2026 use cases where batch input stays relevant

Three scenarios continue to justify batch input in 2026, despite the availability of LTMC and modern BAPIs.

First scenario: custom Z transaction not covered by a BAPI. You have developed a custom transaction for a specific business process. No public BAPI exposes it. Developing a dedicated BAPI costs more than the need justifies. Batch input through SHDB delivers a working solution in a single day.

Second scenario: mass correction in production. An internal audit reveals that a field was entered incorrectly on several thousand material master records. You have to fix it within two weeks. Launching a BAPI development project plus tests plus transport takes a month. A well-built batch input session on MM02, validated in pre-production, delivers the correction within the week.

Third scenario: S/4HANA rollout with legacy scripts. A subsidiary joins the central deployment. It brings historical BDC scripts for its recurring loads. Rewriting each script in LTMC or in a BAPI takes months. Maintaining batch input for the duration of the transition is also project pragmatism.

For recurring loads of bills of materials (BOM) in the PP module, I long used batch input on CS01 before migrating to the standard BAPI BAPI_MATERIAL_BOM_GROUP_CREATE. For production versions, the case is different: creation goes instead through the standard PP master data APIs. Once you have mastered the BAPI, you do not go back on this kind of load.

On my industrial projects, I have never seen a batch input “eliminated once and for all”. It always comes back, on a Z transaction, a mass correction, or a subsidiary that brings its own scripts. Better to master it well than to pretend you no longer need it.

Pierre Balbinot, SAP PP / EAM consultant

Frequently asked questions about SAP batch input

In summary: batch input, the tactical tool of 2026

Batch input is neither a relic to forget nor the default method for your next S/4HANA project. It is a tactical tool you keep sharp for the cases where LTMC, BAPI, and OData do not cover the need. Master SM35, the SHDB recorder, the three execution modes, and the seven classic pitfalls: you will hold production steady without giving in to the “all LTMC” fashion. The senior reflex is knowing how to pick the right tool for the situation, not replacing your whole toolbox at every version change.

Keep reading

01

SAP Tutorials

Beginner's guide to batch management in SAP MM

I have seen consultants tick the "Batch management" box on thousands of materials in a MASS run, without realizing the batch level was still set at client level. A few...

Pierre B. 12 min read

02

SAP Tutorials

SAP batch determination and management

You are configuring SAP batch determination and the engine does not kick in. You are picking batches in the wrong order even though the sort rule is correctly set up....

Pierre B. 12 min read

03

SAP Tutorials

SAP Serial Number: OIS2 setup and material vs equipment

A SAP serial number is the unique identifier attached to one specific physical unit of a given material. It is the tool for unit-level traceability, the foundation for individualized after-sales...

Pierre B. 15 min read

04

SAP Tutorials

SAP Functional Specification: WRICEF template and pitfalls

Most SAP consultants treat the functional specification as administrative drudgery to dispatch before getting to the real work. Rookie mistake. A well-written FS decides on its own whether the development...

Pierre B. 18 min read