Most SAP data extraction guides for auditors start with the assumption that someone from the client's IT department will be available to help. That assumption is frequently wrong in practice. The client's SAP Basis administrator may be overloaded, unavailable during fieldwork, or simply unwilling to expedite access requests for an audit team that shows up for four weeks a year. The result is that data extraction drags on, fieldwork timelines compress, and the audit team ends up working with whatever partial export the client can provide quickly.
The BKPF and BSEG tables in SAP's Financial Accounting module contain everything needed for journal entry testing. Getting to them through a properly configured RFC connection — without involving Basis — is a matter of understanding the right transaction codes, authorization objects, and connection parameters. This is that reference.
What's in BKPF and BSEG
BKPF is the Accounting Document Header table. Each row represents one journal entry document. The fields auditors primarily need are: BUKRS (company code), GJAHR (fiscal year), BELNR (document number), BLART (document type), BLDAT (document date), BUDAT (posting date), USNAM (username of person who posted), BVORG (cross-company code transaction), and WAERS (currency).
BSEG is the Accounting Document Segment table. Each row represents one line item within a journal entry. One BKPF header document typically has two or more BSEG line items — one debit, one credit, and sometimes additional lines for tax or clearing accounts. Key BSEG fields: BELNR and BUKRS (join keys back to BKPF), BUZEI (line item number), HKONT (general ledger account), SHKZW (debit/credit indicator — S for debit, H for credit), DMBTR (amount in local currency), SGTXT (text/description of the line item).
For a complete journal entry population, you join BKPF to BSEG on BELNR, BUKRS, and GJAHR, filter to the relevant fiscal year and company codes, and you have the complete general ledger transaction file. That's the starting point for every analytical procedure in a SAP engagement.
Authorization Objects You Need
Before trying any of the connection approaches below, verify that the user ID provided for the audit connection has the following authorization objects assigned: F_BKPF_BUK (authority to display accounting documents by company code), F_BKPF_BLA (authority by document type), and S_RFC (RFC authorization for remote function calls). Without S_RFC, programmatic access via BAPI will fail with an authorization error that doesn't always clearly identify the missing object.
To check what authorizations a user ID has: transaction SU56 in SAP, or ask the client to run transaction SU01 and share the role assignments. You're looking for roles that include the SAP_FI_AUTH_001 template or equivalent. If the user ID was created specifically for audit access, it may have only display authorizations without RFC — in that case, transaction SE16N for table browsing is still available without RFC, which is the fallback approach described below.
Approach 1: RFC/BAPI Connection (Preferred)
An RFC connection lets you extract data programmatically without logging into the SAP GUI. AuditPulsar uses this approach in its SAP S/4HANA connector. The relevant BAPI is BAPI_ACC_DOCUMENT_GETLIST for header-level queries, or for larger populations, direct table access via the RFC_READ_TABLE function module.
To set up the RFC connection, you need: the SAP application server hostname or IP address, the SAP system ID (SID, typically a three-letter code like P01 or PRD), the SAP client number (typically 100, 200, or 300), the logon group if the system uses logon load balancing, and user credentials. The message server port is typically 3601 + the SAP instance number; the application server port is 3200 + instance number.
Connection setup in SAP GUI (if testing manually): transaction SM59, create a new entry of type 3 (ABAP connection), enter the target system parameters. For external connections from audit tools, the connection type is type G (HTTP/HTTPS) or direct RFC using the librfc32.dll/libsapjco3 libraries. AuditPulsar handles this via the SAP Java Connector (JCo) with parameters that are configurable in the platform's ERP connector setup screen.
Approach 2: SE16N Table Browser (No RFC Required)
When RFC access is unavailable or the authorization setup is taking too long, transaction SE16N provides direct table browsing within the SAP GUI. Navigate to SE16N, enter table name BKPF or BSEG, set the selection criteria (company code, fiscal year, posting date range), specify the maximum number of records to return, and execute.
The output can be exported to a spreadsheet via the standard SAP export function (System > List > Save > Local File, or the download icon in the output). For BSEG, which can contain millions of rows for large clients, you'll need to extract in chunks by date range or document number range to avoid timeouts and file size limitations. Export each chunk to CSV and combine after extraction.
One important note on SE16N access: in many SAP systems, SE16N is restricted to users with development or super-user roles because it bypasses certain display authorizations. If SE16N returns an authorization error, the alternative is transaction FB03 (Display Accounting Document) for individual document lookup, or a custom ABAP report if the client's IT team is willing to run one.
Approach 3: SAP Query via Transaction SQ01
For clients who are cooperative but whose IT teams can't configure an RFC connection quickly, transaction SQ01 (SAP Query) allows end users to create ad-hoc reports against specific tables without ABAP development skills. The user creates a query against the BKPF and BSEG info objects, specifies the selection criteria and output fields, and runs the report. Output can be exported to Excel.
This approach requires that the user ID have authorization for SQ01 and that the FI info objects be available in the query repository. In standard SAP installations, these are present but may be restricted. It's worth asking the client's finance team whether they use SQ01 for their own GL analysis — if they do, the required authorizations are likely already in place.
Extracting the Authorization History (USNAM and Change Documents)
For manual journal entry testing, the posting user (USNAM in BKPF) is one of the key data points. But USNAM only shows who posted the document — it doesn't show who changed it after initial posting. For a complete authorization picture, you also need the change document log.
Table CDHDR contains the change document header for all SAP change logs. Filter by OBJECTCLAS = 'BELEG' (accounting document) to get changes to journal entries. The corresponding CDPOS table has the individual field changes with before and after values. Joining CDHDR and CDPOS to BKPF via the OBJECTID field (which corresponds to the document number and company code) gives you a complete post-posting modification history for any journal entry in the system.
This is particularly relevant for testing management override risks: an entry that was originally posted by a staff accountant and subsequently modified by a controller with no documented reason for the change is exactly the type of item that warrants further investigation.
Common Extraction Errors and Fixes
The most frequent issues in SAP data extraction for audit purposes:
RFC_NO_AUTHORITY error: The user ID is missing S_RFC authorization. The client's Basis team needs to add the appropriate authorization object. This is a five-minute fix if the Basis administrator is available. If not, fall back to SE16N.
Record count mismatch between BKPF and BSEG: Normal. Every BKPF header has at least two BSEG line items. After joining, the BSEG line count should be approximately 2.5 to 4x the BKPF count for most ledger populations. If the ratio is wildly different, check whether your filter criteria in the join are excluding valid records.
Amount field shows zero in DMBTR: Some line items carry the transaction amount in WRBTR (amount in document currency) rather than DMBTR (amount in local currency) when the transaction was recorded in a foreign currency. For multi-currency clients, include both fields and use DMBTR when available, WRBTR when DMBTR is zero.
Missing recent entries: SAP's table buffering can occasionally cause recent entries to not appear in SE16N queries immediately after posting. For the period-end population specifically, verify the extraction includes entries up to and including the hard close date by checking the maximum posting date (BUDAT) in your extract against the client's confirmed close date.
How AuditPulsar Handles the Extraction
AuditPulsar's SAP connector automates the extraction steps above. During setup, you provide the RFC connection parameters and the date range for the audit period. The connector authenticates, pulls the BKPF and BSEG populations via RFC_READ_TABLE in batched requests of 50,000 records each, joins the results in memory, and loads the combined dataset into the platform's anomaly detection engine. The entire process for a 200,000 entry engagement typically completes in 8 to 12 minutes.
If RFC access is unavailable, the platform accepts a CSV import of the combined BKPF/BSEG data with column mapping to the expected field names. The import screen includes a mapping template that specifies exactly which SAP fields correspond to which platform fields, making it straightforward to prepare the file from a SE16N export.
The goal is to eliminate the extraction friction that currently causes audit teams to work with incomplete populations. A complete journal entry test starts with a complete population, not a sample of what was easy to get.