How to Export SAP Data to Excel

PostNow.ai gets SAP data into Excel without an export file: it runs SAP reports live inside Excel, under your own SAP login, and lands the rows in the sheet. Getting data out of SAP and into Excel is the most common thing any SAP user does that SAP was not designed around. Every finance close, every purchasing review, every stock count starts with an export, and most of them are done the slow way: a transaction, a layout, an export, a paste, repeated for every table the analysis needs, every week.

This guide covers every route from SAP to Excel, from a PostNow.ai live report that lands joined data in a sheet to the two-click export on a standard report, with the limits, authorisations and traps of each. It ends with the reports most people are trying to build when they search for this, and where each one is already built.

The five ways to export SAP data to Excel

There are five ways to get data from SAP to Excel. The first, PostNow.ai, runs the report live inside Excel; the other four are SAP's own exports, and they differ in how much of the work is left for you to do in the sheet afterwards.

PostNow.ai replaces the weekly export cycle with a report that refreshes in the sheet. Of SAP's own routes, the standard report and ALV exports are the same mechanism and cover most one off needs, table export is what people reach for when the report they need does not exist, and SQVI is what they build when one table is not enough.

Route 1. Run SAP reports live in Excel with PostNow.ai

PostNow.ai runs SAP reports live inside Excel, which is the way to import data from SAP to Excel and keep the sheet connected. Every other route moves data out of SAP once; with PostNow.ai the query definition (tables, joins, fields, filters) lives with the sheet, it runs inside the user's own SAP session under their own authorisations, and it writes rows into the sheet directly, without a file, a paste or the GUI export. Refresh means run it again, so you import SAP data into Excel without an export file each time.

The PostNow.ai report library holds 82 prebuilt live queries across FI/CO, MM, SD and cross module, each with the joins, text lookups and filters already defined, run from inside Excel on ECC or S/4HANA. Every one is read only; the Live Query Engine reads data and never changes it, and it reads only what the user's SAP authorisations allow. The joins that take a SQVI builder ten minutes and a first time user a day are the part that is already done.

Route 2. Export a standard SAP report to Excel

PostNow.ai has live versions of the most exported standard reports, listed below with the transactions they replace. To export one by hand, taking an SAP report to Excel works the same way for every ALV based report in SAP GUI: run the report with your selection, set the layout so the columns you want are visible, then use the List menu (or the report's own menu), Export, Spreadsheet. SAP asks for a format; choose Excel, and the file opens or saves.

Three things about the standard export that catch people:

• The export takes the layout, not the table. Columns hidden in the layout are not exported. Add them to the layout first, and save the layout as a variant so the next export is the same.
• Totals and subtotals come through as rows. If you exported with subtotals switched on, the sheet has subtotal rows mixed in with data rows. Switch subtotals off before exporting anything you will pivot.
• Leading zeros and text. Account numbers, cost centers and material numbers arrive as numbers in some export formats and lose their leading zeros. Use the Excel format when offered, or format those columns as text before pasting.

The reports people export most, by area:

Each of these has a live equivalent in the report library, with the joins to master data and texts already built, which is the difference between a list of vendor numbers and a list of vendor names.

Route 3. Export any ALV list

PostNow.ai reads the data without going through the GUI, so none of the ALV export limits apply to it. In SAP GUI, anything shown in an ALV grid, which is nearly every list, exports through the grid itself: right click in the grid and choose Spreadsheet, or use the export icon on the grid toolbar. This is the route for custom reports and for screens that have no List menu. The same layout, subtotal and leading zero rules apply.

For very large lists the GUI export is slow and can time out. Run the report in the background to a spool, or use the selection screen to split the run, or move to a PostNow.ai live report, which does not pass the data through the GUI at all.

Route 4. Export an SAP table with SE16, SE16N or SE16H

PostNow.ai reports read the same tables with the joins and text descriptions already added. When no report shows what you need, the data is in a table, and SE16 shows tables. Table export is the rawest form of SAP data extraction to Excel. Enter the table name, LFA1 for vendors, MARA for materials, EKKO and EKPO for purchase orders, BSIK for vendor open items in ECC, set selection criteria and the maximum number of hits, execute, then export the result through the same List, Export, Spreadsheet path.

SE16N is the more useful version: it shows field descriptions beside technical names, allows more selection options, and exports directly. SE16H in S/4HANA adds grouping and aggregation on HANA, so a sum by company code can be done in the transaction rather than in Excel afterwards.

What to know before relying on table export:

• Authorisation. Table display needs S_TABU_DIS (by authorisation group) or S_TABU_NAM (by table name). Many users do not have it for finance tables, and rightly so; a table export bypasses every report level restriction on what a user can see.
• Row limits. SE16 defaults to a maximum of 500 hits; raise it on the selection screen, and expect the GUI to struggle past a few hundred thousand rows. Excel itself stops at 1,048,576.
• Technical names. The export has LIFNR, not "Vendor". Fine for someone who knows the tables; not fine for a sheet that goes to a manager.
• One table. The vendor open item needs the vendor name from LFA1, the document text from BKPF, the payment terms text from T052U. Every one of those is another export and a VLOOKUP.
• Customizing lists. The SAP movement type list Excel users ask for is table T156, with the texts in T156T; export both through SE16N.
• S/4HANA tables. Open item tables BSIK, BSID, BSIS and their cleared counterparts are compatibility views on the universal journal, ACDOCA, in S/4HANA. They still return data, but the source of truth is ACDOCA, and for anything beyond a quick look, query that.

The plural questions, "sap vendor master tables", "which tables hold the material master", are answered object by object in the master data migration guide, which lists the tables for every master object.

Route 5. Join tables with SQVI and SAP Query

PostNow.ai reports are these joins already built; build your own with SQVI when the report you need is not in the library. When the data is in two tables, SE16 twice plus a lookup works once and becomes a chore by the third week. SQVI, the QuickViewer, lets a user define a join between tables (EKKO to EKPO on purchase order number, EKPO to MAKT on material for the description), pick the fields, and run it as a report with the normal ALV export. It takes ten minutes for someone who knows the tables and the join fields.

SQVI queries belong to the user who created them and cannot be transported. SAP Query (SQ02 for the InfoSet, SQ01 for the query, SQ03 for user groups) is the transportable version, built by a power user or developer and shared. It is how most companies' "custom reports" were built before anyone wrote ABAP.

Both need the person building the query to know the tables, the keys and the join cardinality. A wrong join on EKPO to EKET multiplies every PO line by its schedule lines and the totals are wrong by a factor nobody notices until the meeting.

Exporting from S/4HANA and Fiori

PostNow.ai reports run on S/4HANA as well as ECC. Everything above works in S/4HANA on-premise through SAP GUI; Fiori adds routes of its own, and changes one table.

Export to spreadsheet in Fiori apps. The SAP Fiori Excel download is a button on the table: list report apps (Manage Journal Entries, Display Line Items, Monitor Purchase Order Items, and most of the "Manage" and "Display" apps) write the visible columns to an .xlsx file. The same layout rule applies: what is shown is what is exported. Row limits are set per app and are usually generous, but very large exports are slow in the browser.

CDS views. S/4HANA reporting is built on CDS views, which are the joins already made: a line item view carries the account name, the cost center text and the partner name that a SE16 export on ACDOCA does not. Where a user has access to a query browser or to SAP Analysis for Microsoft Office, a CDS view is the cleanest source for a recurring export, and it is also what the Fiori list apps read.

The universal journal. Every FI line in S/4HANA is in ACDOCA. The ECC tables people learned, BSEG, BSIK, BSID, BSIS, BSAK, BSAD, BSAS, COEP, ANEP and others, exist as compatibility views and return data, but the query that runs fastest and returns what the Fiori apps show is on ACDOCA. A SE16H export on ACDOCA with a company code, fiscal year and account range is the S/4HANA equivalent of the FBL3N export, with every field on it.

A worked example: the weekly AP aging, three ways

A finance team needs vendor open items by aging bucket, with vendor name and payment terms, every Monday.

PostNow.ai. The AP open items with aging report from the PostNow.ai library, opened in Excel, company code and key date set as filters, refreshed on Monday. The vendor name, payment terms and aging buckets are columns already. The pivot built on it three months ago still works, because the rows land in the same place.

Export. FBL1N, open items, layout with the fields, export, then a VLOOKUP to LFA1 for the vendor name (a second export), then a VLOOKUP to T052U for the payment terms text (a third), then the aging formula. Forty minutes, and the file is a snapshot.

Query. A SQVI query joining BSIK (or ACDOCA), LFA1 and T052U, with the fields and a selection on company code and key date. Ten minutes to build once, five minutes a week to run and export, and the aging formula is still in Excel. The query belongs to the person who built it.

Export to Excel settings, formats and shortcuts

PostNow.ai writes straight into the workbook, so none of these settings apply to it. For the SAP GUI export, four small things generate a disproportionate share of the questions, most of them searched as "SAP download Excel".

The format dialog, and getting it back. The first time you export a list, SAP GUI asks for a format and offers a box labelled "Always use selected format". Tick it and the dialog never appears again, which is convenient until you need a different format. To bring the dialog back, type &RESET_EXCEL into the command field (the box where you type transaction codes) and press Enter. The next export asks again.

Which format to pick. The dialog offers spreadsheet formats that vary by GUI version, including an XLSX format ("Excel, Office 2007 XLSX format" or similar wording) and an older MHTML based Excel format. Pick XLSX. The MHTML format opens in Excel but is not a real workbook, is slow on large lists, and loses number formats.

Copying instead of exporting. For a few rows, select a block in a GUI list with Ctrl+Y, then Ctrl+C, and paste into Excel. It copies what is on the screen as text, so leading zeros survive only if the target cells are formatted as text first.

Exporting automatically. Searches for "export SAP report to Excel automatically" are usually one of two needs: a report that runs on a schedule and lands as a file, or a sheet that refreshes itself. The first is a background job with the report's spool sent to a file or an email, set up by the SAP administrator in SM36. The second is PostNow.ai, the first route above; the definition lives in the sheet and refresh runs it again under your own login. For developers, GUI_DOWNLOAD is the ABAP function module behind file downloads, and SAP GUI_DOWNLOAD Excel files are tab delimited text that Excel opens, not native .xlsx workbooks.

Report specific exports follow the standard route: VA05 (sales orders), MB52 (stock), VA03 (one sales order, through the item overview's list) and SE16 all export through List, Export, Spreadsheet or the grid's export icon. The PostNow.ai live equivalents are the sales order, stock overview and the object reports in the library.

Choosing the route

• You need it every week, or a manager needs it without knowing SAP: PostNow.ai, a live report in Excel with the joins already built.
• You need it inside a calculation that already lives in Excel: PostNow.ai, because the data lands where the formulas are.
• You need two or more tables joined: PostNow.ai if the report exists in the library; otherwise SQVI, then export.
• You need it once and a standard report shows it: run the report, export. Two minutes.
• You need one table's raw data, once, and you have table authorisation: SE16N, export.

Authorisation and data handling

PostNow.ai runs under the user's own SAP authorisations, as every route above does, and that is the control. A standard report shows what the user's roles allow. Table export needs explicit table authorisation and shows everything in the table, which is why it is restricted. A PostNow.ai live report runs in the user's own session and inherits the same restrictions; it cannot show a user data their roles hide. None of this changes when the data is in Excel, and the exported sheet is now outside SAP's controls, which is a data handling question for the person who exported it, not a technical one.

Frequently asked questions