How to do an SAP SD mass upload from Excel
PostNow.ai does an SAP SD mass upload from Excel one object at a time, in load order: customers, prices, sales orders, deliveries, billing. Each object has its own template on a BAPI or a recording, such as BAPI_SALESORDER_CREATEFROMDAT2 for VA01. Validate checks the file offline, Simulate shows SAP's messages first, and Run writes each document number back to its row.
- SAP sales automation from Excel is the same route. Order entry, price changes, deliveries and billing run as published templates that operators run under their own SAP login.
- Read the order, not only the Run Log. SAP saves incomplete and credit-blocked orders as successes, so check them after every load.
This page is the map for sales and distribution: which SD object comes first, which route PostNow.ai uses for each, and what to check when the run is over. Each object has its own how-to page, linked from the tables below. For choosing a method across all SAP modules, see SAP mass upload from Excel.
What SAP SD mass upload covers
PostNow.ai covers SAP SD mass upload for the five objects a sales team loads from spreadsheets: customer master, pricing conditions, sales orders, outbound deliveries and billing documents. Two of them are master data that every order reads; three are documents, each created with reference to the one before it.
| SD object | Transaction | What one Excel row usually is | How-to page |
|---|---|---|---|
| Customer master | XD01 (ECC), BP (S/4HANA) | One customer with one company code and one sales area | XD01 customer master upload |
| Pricing conditions | VK11 | One condition record: condition type, key, price, validity | VK11 pricing conditions upload |
| Sales orders | VA01 | A header row, then one row per item | VA01 mass upload |
| Outbound deliveries | VL01N | One sales order item and the quantity to ship | VL01N mass delivery creation |
| Billing documents | VF01 | One delivery or sales order to bill | VF01 mass billing |
Two neighbours sit just outside the five. Materials need their sales views before anyone can order them, which the MM01 material upload covers. Customer credit limits decide whether an order is blocked on save, which the FD32 credit limit upload covers.
SAP sales automation from Excel: what it covers
PostNow.ai automates the SAP sales steps that start in a spreadsheet: a distributor's order file, a new price list, a list of orders to ship today, a month-end billing selection. A designer builds the template once against your SAP system and publishes it; customer service, pricing and shipping staff then run their own files through it, under their own SAP login, and get SAP's answer on every row.
| Sales task | PostNow.ai route | SAP's own route for the routine case |
|---|---|---|
| Enter orders that arrive as spreadsheets | VA01 template on BAPI_SALESORDER_CREATEFROMDAT2 | EDI: IDoc ORDERS with process code ORDE, for customers with a system connection |
| Load a new price list | VK11 recording, one condition record per row | Manage Prices – Sales app (S/4HANA) |
| Change open orders in bulk | Mass Change: read the orders into Excel, edit, post the changes with BAPI_SALESORDER_CHANGE | VA02, one order at a time |
| Ship a chosen list of orders | VL01N template on BAPI_OUTB_DELIVERY_CREATE_SLS | VL10 delivery due list, by shipping point and date |
| Bill a chosen list of deliveries | VF01 recording or BAPI_BILLINGDOC_CREATEMULTIPLE | VF04 billing due list, or VF06 as a background job |
| Report on the result | Report Library: Sales Order 360, Open Sales Orders, Billing / Invoice 360 | VA05, VL06O, VF05 |
The rule we work by: when SAP's own route can express the selection ("everything due by Friday for shipping point 1010"), use it, and schedule it. A file earns its place when someone has made a decision outside SAP: these 40 orders from a distributor, these prices from the commercial team, these deliveries billed today and not the rest. Changes to existing orders go through SAP mass change from Excel, and the controls that make a template safe for a team (run-only published templates, approvals, central audit) are on Excel to SAP automation.
Quotations, returns and credit memos are sales documents too. PostNow.ai's Find with AI suggests BAPI_QUOTATION_CREATEFROMDATA2 for VA21 quotations, and the free sales and distribution templates include a returns order and a credit memo request on VA01. Keep each document type in its own file: a returns order brings goods back, and a credit memo request is typically created with a billing block that someone with authority releases.
How PostNow.ai runs an SD upload
PostNow.ai runs every SD object through the same six steps; only the template underneath changes.
1. Pick the BAPI or record the transaction
In the BAPI Explorer, search your system or ask Find with AI: its transaction list maps VA01 to BAPI_SALESORDER_CREATEFROMDAT2, VL01N to BAPI_OUTB_DELIVERY_CREATE_SLS and VF01 to BAPI_BILLINGDOC_CREATEMULTIPLE. PostNow.ai reads the interface from your system, so the mapper shows the parameters your release has. For XD01 and VK11, record the transaction once instead.
2. Map the columns
Orders use header and item rows: the H row carries order type, sales area, sold-to and customer PO number, and the D rows under it carry material, quantity and date. Customers, condition records, deliveries and billing documents are usually one row each.
3. Fix what should not vary
Give sales organisation, distribution channel and division fixed values or an allow-list with Restrict on, so Validate refuses a sales area the template was not built for. Switch on Leading Zeros for customer and document numbers, so 4471 reaches SAP as 0000004471.
4. Validate, then Simulate
Validate checks the file offline: required fields, lengths, formats, dates and allowed values. Simulate then asks SAP: a BAPI template calls the BAPI and rolls back instead of committing; a recording replays the screens without the final save. Either way you read SAP's messages per row. The billing BAPI is the exception to plan for: it commits inside SAP, so test it with its own TESTRUN flag on a quality client.
5. Run, and write the document number back
Run commits a BAPI call only when SAP returns no E or A message and rolls it back otherwise. Recordings run as CALL TRANSACTION with synchronous update, so each row's messages and document number return at once in the Run Log. The order, delivery or billing number lands in its own column, and with VA03, VL03N or VF03 as the Call Transaction it opens the document in one click.
6. Re-run only what failed
Retry Failed re-posts only rows whose Run Log starts with ERROR, scanning from the current Start Row down. A normal Run first reads the Run Log and, if rows in scope already hold a document number, offers Skip posted rows, Post again or Cancel. A row marked UNKNOWN lost SAP's answer after it may have posted: look it up in SAP before you post it again.
Every run is also written to PostNow.ai's central audit with template, SAP system, client, user, result and document number. When a row fails, AI Review in the run diagnostics explains SAP's messages; by default it receives the messages, the BAPI name and the field structure, never the cell values.
Which SD object to load first
PostNow.ai runs one template per object, so the load order is yours to set, and SAP's dependencies set it for you: each object reads the one above it when it is created.
| Order | Object | Must already exist | What happens if it does not |
|---|---|---|---|
| 1 | Customer with sales area data | Account group or BP grouping, number range, sales area in Customizing | The customer cannot be saved for that sales area |
| 2 | Material sales views | Material, sales organisation and distribution channel views, delivering plant | The order item is rejected for that material |
| 3 | Credit limits | The customer | Orders save and wait on a credit block |
| 4 | Pricing conditions | Customer and material for customer- or material-specific keys | No error at load time; the orders get no price from that condition |
| 5 | Sales orders | All of the above in the order's sales area | See the silent failures below |
| 6 | Deliveries | A sales order with a schedule line due by the selection date | No delivery is created for the item |
| 7 | Billing documents | A delivery with goods issue posted (delivery-related billing) or an order (order-related billing) | The reference is not billed |
The row to watch is pricing. A customer or material that is missing stops the order with an error that names it. Prices that are missing, or found in a condition table the pricing procedure never reads, let the order save. So prove the price list before the orders: load the condition records first, then create one test order per price pattern and read its condition analysis in VA03. Picking and goods issue between delivery and billing are a warehouse step, covered on the VL01N page.
The BAPI or recording for each SD object
PostNow.ai posts through a BAPI where SAP offers one that fits, and through a recording of the transaction where it does not. This is the route we build each SD template on, and why.
| Object | PostNow.ai route | Why this route | Number written back |
|---|---|---|---|
| Sales order (VA01) | BAPI_SALESORDER_CREATEFROMDAT2, one call per order | No screens, so items with no stock or an incompletion dialog do not break the run; a VA01 recording suits one-item orders | Order number from SALESDOCUMENT |
| Customer (XD01, ECC) | XD01 recording, one customer per row | General, company code and one sales area in one save | Customer number from SAP's save message |
| Customer (BP, S/4HANA) | BAPI_BUPA_CREATE_FROM_DATA for the business partner | XD01 redirects to BP on S/4HANA, and SAP does not support BP for batch input (KBA 1951318); the customer's company code and sales area data go through one of the released interfaces listed in SAP Note 2417298 | Business partner number |
| Pricing conditions (VK11) | VK11 recording, one template per condition type and key combination | SAP Note 1135984 says BAPI_PRICES_CONDITIONS is not released and can cause inconsistencies | SAP's message per row |
| Outbound delivery (VL01N) | BAPI_OUTB_DELIVERY_CREATE_SLS, one call per order or group | Partial quantities per line without addressing VL01N's item table by position | Delivery number from DELIVERY |
| Billing document (VF01) | VF01 recording, or BAPI_BILLINGDOC_CREATEMULTIPLE | The recording is short and Simulate can replay it without the save; the BAPI commits inside SAP, so test it with its TESTRUN flag on a quality client first | Billing number from SAP's message or the BAPI's SUCCESS table |
Which method suits which kind of object in general is on BAPI vs BDC in SAP, and how to record a transaction so it replays reliably is in the BDC recording guide. Free Excel templates for VA01, VK11, VL01N and VF01, each with a column-to-field guide, are on the sales and distribution templates page.
What your file supplies, and what SAP determines
PostNow.ai sends SAP only what the template maps; everything else on a sales order comes from SAP's determination, exactly as when an order is keyed in VA01. That is why a short file produces a full document, and why a wrong document can come from a correct file.
| On the sales order | Comes from | Put it in the file? |
|---|---|---|
| Order type, sales area, sold-to, material, quantity, requested date | Your file | Always |
| Customer PO number | Your file | Yes: with the PO number check on the order type (VOV8), SAP warns with V4 115 when the sold-to already has an order with that number |
| Ship-to party | If none is sent, SAP uses the sold-to as ship-to | Yes, for any customer with more than one delivery address |
| Bill-to and payer | Partner determination from the customer master | No, unless a row needs an exception |
| Price | Condition records, read through the pricing procedure that the sales area, the customer and the order type select | No; load the condition records instead |
| Delivering plant | Master data proposals | Yes, in a multi-plant network: it decides which stock is checked |
| Shipping point | Shipping condition (customer), loading group (material) and plant | Only if your business overrides SAP's proposal |
| Confirmed quantity and date | The availability check | Never; SAP decides it |
An order created from a file goes through the same determination as one keyed in VA01, so for a mass load the consequence is simple: when an order is wrong, look at the master data and condition records before you look at the file. The one test order per price pattern from the load order above catches most of it before the full file runs.
Four silent failures in sales order loads
PostNow.ai marks a row by what SAP did: committed, or rolled back with SAP's error. SAP also saves orders that still need someone's attention, and these four show as a success in the Run Log.
| What happened | What SAP does | How you find it | What to do |
|---|---|---|---|
| Incomplete order | Saves the order with warning V1 555 "The sales document is not yet complete" where the order type allows it | The Run Log cell shows SAP's first non-warning message, so V1 555 is not in it: use V.02 or the Incomplete / Blocked Orders report | Complete the order in VA02; do not re-run the row |
| Credit block | Saves the order with credit status B, often with no credit message in RETURN | VKM1 on ECC, or your credit release process on S/4HANA | The credit team releases it; a re-run creates a second order |
| Short stock | Saves the order and confirms what it can; the rest moves to a later schedule line or stays unconfirmed | Confirmed quantity on the schedule line in VA03, or Sales Order 360 | Sort the file by the agreed priority, because each order consumes stock before the next one is checked |
| Missing price | Saves the item without that condition's value; if the pricing procedure marks the condition mandatory, warning V1 801 "Pricing error: Mandatory condition … is missing" and the order is incomplete | Net value in the file against VA03, and the condition analysis on the item | Load or correct the condition record, then update pricing in VA02 |
Worked example: a new distributor, a price list and 39 orders
PostNow.ai runs this as five templates in load order. A distributor, customer 200371, starts buying from sales organisation 1010, distribution channel 10, division 00, with a price list valid from 01.12.2026 and a first order file of 40 orders.
- Customer. The XD01 template extends
200371to sales area 1010/10/00 with its shipping condition, payment terms and partner functions. Customer Master Sales 360 (SD-01) confirms the sales area data. - Materials. Material Sales 360 (SD-02) shows that every material in the price list,
TG-1001among them, has its sales view for 1010/10 and plant1010. - Prices. The VK11 template for PR00 on Customer/Material (table A305) loads 120 records valid from 01.12.2026. One test order for
TG-1001shows in the condition analysis that PR00 is found in A305 at the agreed price. - Validate and Simulate the orders. The order file has 40 orders and 112 items. Validate stops two rows with division
01, which the allow-list refuses; the distributor corrects them. Simulate returns an error for one order whose ship-to has no data in this sales area, so that order leaves the file. - Run. 39 orders get numbers. The Incomplete / Blocked Orders report (SD-16) lists two orders on the incompletion log, which customer service completes in VA02, and one order on credit block goes to the credit team. Sales Order 360 shows four items confirmed for a later date, and the distributor is told.
- Ship and bill. The shipping team runs the VL01N template for the confirmed items, and after goods issue, the VF01 template bills the deliveries.
Checklist before an SAP SD mass upload
PostNow.ai enforces formats and allow-lists in the template; these decisions stay with the sales team.
- Every customer in the file has data for the exact sales area on its rows, and every material has its sales view there.
- Condition records are loaded and one test order per price pattern shows the expected record in the condition analysis.
- Each file holds one document type: standard orders, returns and credit memo requests go in separate files.
- Ship-to and delivering plant are columns wherever the default would be wrong.
- The customer PO number is mapped, so SAP's duplicate PO check can warn.
- The sheet is sorted by the agreed priority for materials that may be short.
- Someone owns the incomplete, credit-blocked and partly confirmed orders after the run.
- The warehouse and billing know what the run will add to their due lists.
Checking the result of an SD upload
PostNow.ai gives you the first check on every row: the Run Log, the document number column with its display link, and the central audit. Then read what SAP created.
- Sales orders. VA03 for a sample from different customers: partners, the condition analysis on an item, net value and the confirmed quantity. VA05 lists the run's orders by sold-to or PO number, and V.02 lists incomplete ones.
- Deliveries. VL03N for a sample and VL06O, the outbound delivery monitor, for the whole run.
- Billing. VF03 for a sample, where you check that the accounting document was created, and VF05 to list the run's billing documents.
- Report Library in PostNow.ai. The sales order report in Excel (Sales Order 360) lists the new orders with header, items, schedule lines and status, and the billing and invoice report (Billing / Invoice 360) does the same for the billing documents. Operators run both under their own SAP authorisations.
Reconcile on three numbers per run: documents in the file against documents created, requested against confirmed quantity, and expected against actual net value. A run where every row is green but a third of the quantity is unconfirmed has not finished its job.