SAP Billing (Sales) Report

What the billing report shows

A SAP billing report answers a simple question that SAP makes surprisingly hard: give me every billing record, with all the attributes that matter, in one place I can filter and share. On screen, SAP shows one record at a time and splits its attributes across several views. This report flattens all of that into a single Excel sheet, one row per record, with the codes turned into readable labels.

Because the output is a plain sheet, it becomes the starting point for the work people actually do with it: a data-quality review, a cleanup before a migration, a hand-off to an auditor, or a source for a pivot. The value is not just the extract, it is that the extract is complete and consistent every time you run it.

A billing report is where sales and finance meet, so it tends to serve two audiences at once. Sales want the invoice register by customer, material and period to see what was billed; finance want the same data tied to the ledger for a revenue reconciliation. Because the report carries both the billing detail and the reference that links each invoice to its accounting document, one extract answers both, instead of two teams building two spreadsheets from the same underlying documents.

The SAP tables behind it

A billing document is a header with items. VBRK holds the billing header: billing document VBELN, billing type, billing date, sales org and the sold-to and payer. VBRP holds the items, keyed by VBELN plus item, with material, billed quantity and net value, and it carries the reference to the source sales order in AUBEL. The customer name is joined from KNA1 on the sold-to KUNAG. Because billing posts to accounting, the billing document links to the financial document in BKPF through the reference, so a billing report can be reconciled to the ledger. Keyed at item level, each invoice line is one row.

The joins are the whole reason this is worth automating. Miss one and the report is subtly wrong; get the key fields slightly off and rows fan out or drop. Doing it once, correctly, and then reusing it is what turns a fragile spreadsheet exercise into a reliable report.

The columns you get

Every column below is a real SAP field, labelled in plain English, with the table it is read from. These are the fields most teams want on a billing report; a tool like PostNow lets you add or remove columns without touching the underlying join.

Building it yourself: VF03, SE16 or SQVI

VF03 shows one invoice and VF05 lists invoices for a customer or material, but with a fixed layout. SE16 on VBRK and VBRP gives the header and items, matched on the billing document in Excel, plus KNA1 for the customer name. Reconciling billing to accounting means bringing in the reference link to BKPF, which is not a straight join. A refreshable invoice register with tax and the accounting link is a developer task rather than a quick export.

None of this is impossible; people do it every month. The problem is that it is manual, easy to get subtly wrong, and stale the moment it is saved. Each refresh means repeating the same exports and the same lookups, and any new column means another round with a developer. For a one-off you can push through it. For a report you run every period, the cost adds up. If you want the general landscape of options first, see our overview of SAP reporting tools and how to get SAP to Excel.

The out-of-the-box way: PostNow's billing report

PostNow's Report Library already contains this exact report, pre-built. You do not assemble the joins or resolve the texts; that is done for you. You open Excel, log in to postnow.ai from the task pane, pick the billing report, set your range filters, and run. The governed, joined data lands in the sheet, ready to filter, pivot or share, and you can refresh it whenever you need the latest.

Two things make this different from a SE16 dump. First, it is governed: PostNow enforces your own SAP authorizations, so you only ever see the data you are entitled to, and every row can be traced back to its source. Second, it is repeatable: the same report, the same columns, refreshable on demand, with no ABAP to write or maintain. That is the payoff of teaching the hard version first, then handing you the shortcut.

Filters and selection you'll want

A good billing report is only as useful as the selection you can put on it. The filters most teams reach for are:

• Billing document range (VBELN)
• Sold-to / payer (KUNAG)
• Sales organization (VKORG)
• Billing type (FKART)
• Billing date (FKDAT range)
• Material (MATNR)

You set these once as your selection, then reuse or adjust them each run. Because the selection travels with the report, a monthly extract becomes a single refresh rather than a rebuild.

ECC vs S/4HANA

Billing documents post to accounting, and the billing header VBRK links to the financial document header BKPF through the reference (AWKEY). This holds on both ECC and S/4HANA, so a billing report can be reconciled to the ledger on either release; PostNow reads the tables through standard interfaces.

The practical takeaway is that a report built on the tables and read through standard interfaces survives a migration far better than one wired to a specific screen or a custom program. When you eventually move from ECC to S/4HANA, a table-based billing report keeps working, which is one less thing to rebuild in an already large project.

Frequently asked questions