SAP Data Upload Methods

What SAP data upload methods means

SAP data upload methods are the mechanisms available for getting data from a file into SAP at volume: published function modules and APIs, screen recordings, the legacy migration workbench, keystroke automation, and direct writes to database tables. They are not equivalent, they are not interchangeable, and the differences between them decide whether a load is a controlled process or a liability.

This page is the hub for that decision. Every other guide in this cluster assumes a method has been chosen and describes what to do with it. This one covers how to choose, why the order of preference does not change per object, and why two of the six should never be used at all.

For the method-neutral foundation, the SAP mass upload pillar guide covers the validation and governance that apply regardless of method.

The question is not which is fastest

Every one of these methods will move data into SAP. Measured on throughput alone they are closer than people expect, and the fastest is the one nobody should use. Speed is not the axis that matters.

The question worth asking is: which of these still applies SAP's own rules when your file goes through it?

SAP contains a great deal of logic that has nothing to do with storing values. Field validation against check tables. Business rules like document balance and mandatory field combinations. Dependent updates to index and totals tables. Change document creation. Number range assignment. Locking so two processes cannot touch the same record simultaneously.

A method that goes through the transaction or its published interface inherits all of that for free. A method that goes around it inherits none of it, and the resulting records look correct while behaving wrongly.

Choosing a method in four questions

The tree settles it for almost every object, and the order never changes. What changes is how far down you have to go before something applies.

Is there a published interface?

A BAPI, or on S/4HANA a released OData service, is the answer wherever one exists. SAP publishes these precisely so that external systems can create records the same way the transaction does. They apply the same validation, write the same change documents, and return a structured message per row rather than a screen you have to parse.

Coverage is good for the objects that carry volume. Every transaction in this cluster has one: BAPI_ACC_DOCUMENT_POST for journals, BAPI_MATERIAL_SAVEDATA for material master, BAPI_PO_CREATE1 for purchase orders, BAPI_SALESORDER_CREATEFROMDAT2 for sales orders, BAPI_GOODSMVT_CREATE for goods movements, BAPI_INCOMINGINVOICE_CREATE for invoices.

Is the transaction stable and non-Fiori?

Where no interface exists, a screen recording replays the transaction, filling fields in sequence as a person would. Coverage is universal because anything you can do on a screen can be recorded. The cost is fragility: the recording is tied to that screen, and a support pack, a configuration change or a different field status can break it.

Recordings are an acceptable fallback on stable classic transactions. They are a poor choice where the transaction is being replaced by a Fiori app, which is most of them on S/4HANA.

Is this a one-off pre-migration load on ECC?

LSMW is a real tool that has done real work. It exists on ECC, it handles complex mappings, and for a one-off migration on a system that is not going anywhere it is defensible.

It is not the route on S/4HANA and it is a poor investment for anything recurring. The setup cost per object is heavy, the skills are increasingly rare, and a process built on it needs rebuilding rather than remapping when the system moves. See the LSMW alternative guide for what to do instead.

Is anyone proposing a direct table write?

Stop. This gets its own section below.

What each method actually does

Four differences carry almost all the weight.

Business logic. Interfaces and recordings both apply it, by different routes. LSMW applies it depending on which underlying method it is configured to use, which is a detail people forget when they inherit an LSMW project. Direct writes apply none.

Row-level messages. This is the difference between a recoverable run and an unrecoverable one. A structured message per row tells you exactly which rows failed and why, so failures can be corrected and re-sent. A screen message or a run log means reading and interpreting, which does not scale past a few hundred rows.

Survival. Interfaces mostly survive upgrades and conversions with a remap. Recordings do not survive screen changes. This is the difference between a process you maintain and a process you periodically rebuild.

Auditability. Everything except a direct write produces change documents, so mass loading does not create a blind spot. That is usually the first question a governance function asks, and it is worth being able to answer it immediately.

Direct table writes: why never means never

This is the only recommendation in the entire cluster stated without qualification, so it is worth explaining rather than asserting.

Writing directly to SAP tables skips every layer described at the top of this page. Not some of them, all of them. The record exists in the table and nothing else that should have happened has happened.

• Validation is skipped. Values that no transaction would accept are now present.
• Dependent updates are skipped. Index tables, totals tables and aggregates no longer agree with the line items they summarise.
• Change documents are skipped. There is no record that anything changed, which means no audit trail and no way to answer who did what.
• Number ranges and locking are skipped. Two processes can produce colliding keys.
• Support is skipped. SAP will not help with a system state produced this way, which matters at the exact moment you most need help.

The consequence is not that it fails. It is that it succeeds, and the damage surfaces later as reporting that does not reconcile, balances that disagree with details, or a transaction refusing to process a record for reasons nobody can trace.

GUI scripting sits just above it

Keystroke automation drives the SAP window from outside, typically from a desktop script. It applies business logic, because the transaction is genuinely running, which puts it above a direct write. Everything else is against it: it needs a logged-in desktop session, it breaks on any screen change, it is difficult to audit, and error handling means parsing what appeared on screen. It also runs as whoever left the session open, which is its own control problem. See the GUI scripting alternative guide.

Six questions before choosing

Two of these are asked far less often than they should be.

How often will this run, honestly? Most loads described as one-off return. A month-end accrual, a price list, a plant extension, a receipting backlog: all of them come back. Choosing a method that only works once, because this time is special, is the commonest planning error in mass upload work and the one that costs the most cumulatively.

Who can operate it besides the person who built it? A method that requires its author is a dependency, not a process. This is the practical argument for approaches that live where the business already works rather than in a tool only IT can drive.

One-off or recurring: the question that changes the answer

Of the six questions in the checklist above, this is the one that most often gets answered wrongly, and it changes the method more than any other.

Loads arrive described as exceptional. A migration, a restructure, a backlog, a one-time correction. That framing justifies a method chosen for delivery speed rather than maintainability, because it will only be needed once.

It is usually untrue. Month-end accruals return every month. Price lists return annually and then mid-year when costs move. Plant extensions return with every new site. Receipting backlogs return whenever the warehouse falls behind, which is a recurring condition rather than an incident. Even genuine migrations produce a second wave, a third for the things missed, and a fourth for the entity acquired eighteen months later.

The practical test is to ask what happens the second time. If the answer involves the original builder, or rediscovering the mapping, or hoping the recording still works, the method was chosen for the wrong scenario.

Where PostNow sits in this comparison

Choosing a method, step by step

Error handling is what separates the methods in practice

On a run of twenty rows, every method looks similar. On a run of four thousand, error handling is the whole difference, and it is the dimension least considered when a method is chosen.

A published interface returns a structured result per row. Row 118 failed with message KI 235, row 244 with F5 201, row 301 succeeded and here is its document number. That structure is what makes a partial failure recoverable: the successful rows carry their identifiers, the failed rows carry their reasons, and only the failures are corrected and re-sent.

A screen recording returns whatever appeared on screen. Which is a message, sometimes the right one, in a form that has to be parsed and matched back to the source row. It works, and it degrades quickly as volume rises, because a message that is ambiguous on one row is unusable across four hundred.

A run log tells you what happened in aggregate. Useful for a migration where the whole file either loads or is reworked. Poor for a recurring process where the normal outcome is that most rows post and a handful do not.

A direct write tells you nothing. There is no result because there was no processing.

The practical test to apply to any proposed method is simple: if eleven rows out of four hundred fail, how do I know which eleven and why? A method that cannot answer that cannot support a restart, which means every partial failure becomes a manual reconciliation exercise.

Throughput, and why it rarely decides anything

Method comparisons often start with speed, which is the least useful place to start.

The methods are closer than expected. A screen recording is slower than an interface because it drives a screen, but both are fast enough that runtime is rarely the constraint. What actually determines how long a mass load takes is almost never the method.

• Document count, not row count. Two thousand rows forming four hundred documents makes four hundred calls. Consolidating into fewer documents does more for runtime than any method choice.
• Validation against live data. Checking every row against the system is genuinely work, and it is work worth doing.
• Lock contention. Records held by users or background jobs, which is a scheduling problem rather than a technical one.
• System load. A run during month-end close competes with everything else finance is doing.
• The human stages. Preparing the file, resolving flagged rows and reconciling afterwards take longer than the posting, on almost every run.

Choosing a faster method to save minutes, at the cost of auditability or recoverability, trades something valuable for something that was never the bottleneck.

What S/4HANA does to each method

The conversion is the single largest forcing function on method choice, and it affects the six unevenly.

Published interfaces mostly carry forward. A BAPI-based load usually needs a remap for extended field lengths and changed object models, not a rebuild. This is the practical argument for choosing interfaces before a migration rather than after.

Recordings mostly do not. Where a classic transaction is replaced by a Fiori app, a recording against the old screens is worthless. Even where the transaction survives, screen changes are more likely during a conversion than at any other time.

LSMW is not the route. It is present on some systems and not the recommended path, and building new processes on it before a conversion is investing in something with a known end date.

Released APIs are the modern equivalent. S/4HANA publishes OData services with a release status, and a released service carries the same commitment a BAPI does. Where one exists for your object, it is the natural target.

Direct writes get worse. The simplification programme removed and restructured tables, so code written against ECC table structures does not merely become risky, it stops working. Anyone maintaining direct-write loads discovers this during a conversion, at the worst moment.

Mixed estates and hybrid approaches

Real organisations rarely use one method for everything, and that is fine provided the choice is deliberate per object rather than accidental per project.

A common and defensible pattern: interfaces for the high-volume recurring objects that carry the business, a recording for the one awkward transaction with no BAPI, and nothing else. What causes trouble is the opposite pattern, where the method is chosen by whoever happened to build each load, and the estate accumulates four approaches with four sets of skills and four failure modes.

• Standardise on interfaces where coverage allows. One approach, one set of skills, one thing to remap at conversion.
• Document the exceptions. Which objects use a recording and why, so the decision is revisited rather than inherited.
• Review after every upgrade. A support pack is the moment recordings break and the moment to check whether an interface has appeared.
• Retire rather than accumulate. An LSMW project that still runs is a liability with a date on it.

Governance: the method is a control decision

Method choice is usually treated as technical and is not. It determines whether a load produces an audit trail, whether failures are recoverable, and whether the organisation can prove what changed.

• Ask for the method in the design. Not "we will load the data" but "we will post through this interface". The difference is the whole control question.
• Change documents are the test. If a proposed approach does not produce them, ask why, and treat the answer as the beginning of a conversation rather than a technicality.
• Row-level results are the recoverability test. A method that cannot tell you which rows posted cannot support a restart, which means partial failures become manual reconciliation.
• Named-user execution matters regardless of method. A load should carry the identity and authorisations of the person running it.
• Write the prohibition down. Direct table writes should be a stated policy rather than an assumed norm, because the pressure to make an exception arrives when the policy is not written anywhere.

Mistakes in choosing a method

• Choosing for the first run rather than the tenth. Most one-off loads return, and the method that only worked once has to be replaced.
• Assuming no BAPI exists without checking. Coverage is better than reputation suggests, particularly for high-volume objects.
• Building a recording against a transaction being replaced. The work is thrown away at conversion.
• Starting new LSMW projects. Heavy setup for something with a known end date.
• Accepting a direct write under deadline pressure. The one decision on this page that cannot be quietly corrected later.
• Letting each project choose independently. Four methods across an estate is four sets of skills and four failure modes.
• Treating method choice as purely technical. It decides auditability and recoverability, which are control questions.

The methods guides

• BAPI vs BDC in SAP. The two methods that matter, compared in detail.
• SAP BDC recording guide. How recordings work, when they are acceptable, and how they break.
• SAP LSMW alternative. What to use instead, and how to migrate away from existing LSMW projects.
• SAP mass upload without LSMW. The practical route for teams whose LSMW skills have left.
• SAP GUI scripting alternative. Why keystroke automation is fragile and what replaces it.

Testing a method before you commit to it

Method choice is easier to change before a process exists than after, so it is worth proving one properly on a first object rather than assuming.

Pick the awkward object, not the easy one. A method that handles a simple material master change tells you little. Test it against the object with the most segments, the most validation or the most sequencing dependency, because that is where methods diverge.

Force a partial failure deliberately. Put three rows in the file that you know will fail: a closed period, a blocked record, a missing cost object. Then look at what comes back and ask whether you could correct and re-send from it without cross-referencing anything.

Interrupt a run. Stop it halfway and re-run the same file. If rows post twice, the method or the process around it lacks the status tracking that makes a restart safe.

Check the change documents. Open a record you just changed and confirm the change document looks like a manual edit. If it does not, or if there is none, that is the audit conversation arriving early rather than late.

Have somebody else run it. The person who built a load can always run it. Whether a colleague can is the difference between a process and a dependency.

Who chooses, and who lives with it

Method choice is usually made by whoever builds the first load, often under time pressure, and then inherited by everyone who comes afterwards. That is the wrong shape for a decision with this much downstream consequence.

The builder chooses. Usually a developer or a consultant, optimising for what they can deliver by the date.

The business lives with it. Every month, through whatever operating characteristics the method has. If it needs a developer to run, they wait for one. If it breaks on a support pack, they discover it at month end.

Audit inherits it. Whether there is a trail, and whether anyone can prove what changed, was settled before they were asked.

The migration team inherits it too. Whether the process remaps or rebuilds during a conversion was decided years earlier by somebody who was not thinking about a conversion.

The fix is not complicated: ask the six questions in this guide at design time, write the answer down, and revisit it when the system changes. A method chosen deliberately and documented is a decision. A method chosen by default is a constraint that nobody remembers agreeing to.

Migrating away from a method you regret

Most organisations reading this already have loads built on something they would not choose again. The practical question is what to do about it.

Do not rebuild everything. A recording that works, against a stable transaction, on a system with no conversion planned, is not urgent. Effort spent replacing it produces no visible benefit.

Prioritise by fragility and frequency. The loads worth replacing first are the ones that run often and break often. A quarterly load that has never failed is lower priority than a monthly one that needs re-recording twice a year.

Let a conversion force the order. An S/4HANA project is the natural moment, because recordings need rebuilding anyway. Replacing them with interface-based loads at that point costs little more than rebuilding them as recordings, and produces something that survives the next change too.

Retire direct writes immediately. This is the exception to the measured approach above. A direct-write load is not a technical debt item to schedule, it is an open exposure, and the correct response is to stop using it and assess what it has already done.

Keep the mapping, not the mechanism. The intellectual work in any load is the field mapping and the validation rules. Those transfer between methods. What gets thrown away is the plumbing, which is the cheaper half.

The cost that does not appear in the comparison

Every method comparison table, including the one on this page, measures technical properties. The costs that actually decide whether a mass upload capability succeeds sit outside those columns.

Who prepares the file. If the data lives with finance, procurement or sales, and the loading tool lives with IT, every run needs a handover. That handover is where most of the elapsed time goes, and no method comparison captures it.

How many people can run it. A capability that depends on one person is available when that person is. Holiday, illness and turnover all become process risks.

What happens when it breaks at month end. Not whether it breaks, but who fixes it and how quickly. A method requiring specialist skills has a different failure profile at 6pm on the last working day.

Whether the business trusts it. A load that nobody can inspect gets used reluctantly and second-guessed, which produces manual verification that erases the saving.

These are the reasons a technically inferior method sometimes wins in practice, and the reason a technically superior one sometimes goes unused. Weigh them alongside the table rather than after it.

The complete methods reference

The reference sheet below collects everything above into one image you can share when a method is being chosen.

Go deeper

Frequently asked questions