You have already solved the hard part. Your extraction tool pulls vendor names, invoice numbers, dates, line items, and totals from PDFs. The data sits in a spreadsheet, clean and structured. Now you need to get it into your ERP. This is where most document automation workflows stall.
The problem is not the data itself. The problem is that every ERP has its own import specification. NetSuite expects a CSV with vendor internal IDs in a column called "Vendor." QuickBooks Desktop wants a tab-delimited IIF file with transaction types on every row. SAP requires dates formatted as YYYYMMDD and expects document types that map to specific posting keys. One wrong column header, one misformatted date, one missing required field, and the import fails with an error message that tells you almost nothing about what went wrong.
This guide covers the specific import requirements for the four most common ERPs — NetSuite, QuickBooks, SAP, and Dynamics 365 — and shows you how to format your extracted data so it imports cleanly on the first try. If you are looking for a broader overview of moving extracted data into downstream systems, see our guide on how to get extracted data into your ERP.
Document extraction has improved dramatically in the past few years. AI-powered tools can read invoices, purchase orders, and receipts with near-perfect accuracy. But accuracy in extraction does not mean compatibility with your ERP. The extracted data needs to be transformed before it can be imported, and the transformation rules are different for every system.
Consider date formats alone. NetSuite expects M/D/YYYY (no leading zeros). SAP expects YYYYMMDD (no separators). QuickBooks Online expects MM/DD/YYYY. Dynamics 365 accepts multiple formats but defaults to the locale setting of the importing user, which means the same file might work for one person and fail for another. A single invoice dated January 5, 2026 needs to be formatted as 1/5/2026, 20260105, 01/05/2026, or 2026-01-05 depending on which system you are importing into.
Dates are just the beginning. Vendor identification is another common failure point. NetSuite uses internal numeric IDs for vendors, not vendor names. If your extracted data has "Acme Corp" in the vendor column, the import will fail unless you map that name to NetSuite's internal ID (say, 4523). QuickBooks requires the vendor name to match exactly what exists in your vendor list. "Acme Corp" will fail if the vendor is listed as "Acme Corporation" or "ACME CORP." SAP uses a 10-digit vendor account number. Every ERP stores vendors differently, and your extraction tool does not know which format your ERP expects unless you configure the mapping.
Line item structure creates a third layer of complexity. Some ERPs expect one row per invoice with all line items concatenated. Others expect one row per line item with the header information repeated on every row. NetSuite's CSV import uses a parent-child row structure where the first row contains header data and subsequent rows contain line items. QuickBooks IIF files use a completely different structure with SPL (split) rows for each line item. Get this wrong and it does not just cause an import error. It can create duplicate transactions or post amounts to the wrong accounts.
NetSuite offers two primary import methods for AP bills: the built-in CSV Import tool and SuiteScript for automated workflows. Most teams that are importing extracted document data use the CSV Import tool, accessible at Setup > Import/Export > Import CSV Records, or through the newer Transactions > Import CSV path in newer NetSuite versions.
To import vendor bills via CSV, your file needs these required columns at minimum: External ID (your unique identifier for the bill), Entity (the vendor's internal ID in NetSuite, not the vendor name), Tran Date (transaction date in M/D/YYYY format), and at least one line with an Account (GL account internal ID or name) and Amount. Optional but commonly used fields include Tran ID (the vendor's invoice number, mapped to the Reference Number field), Due Date, Terms, Department, Class, and Location.
The parent-child row structure is the most common source of import errors. The first row for each bill contains the header fields: External ID, Entity, Tran Date, and Tran ID. Subsequent rows for the same bill leave the header fields blank and populate only the line-level fields: Account, Amount, Department, Class, Memo. NetSuite uses the blank header fields to identify which rows belong to the same transaction. If you accidentally populate the Entity field on a line item row, NetSuite will interpret it as a new bill.
Here is what a properly formatted NetSuite CSV looks like for a single bill with two line items:
External ID,Entity,Tran Date,Tran ID,Account,Amount,Memo INV-2026-001,4523,1/5/2026,INV-88012,6010 Office Supplies,250.00,Q1 supplies ,,,,6020 Equipment,1750.00,Monitor purchase
Note the date format: 1/5/2026, not 01/05/2026. NetSuite will accept leading zeros in some configurations, but the safest approach is to strip them. Also note that the Entity value 4523 is NetSuite's internal ID for the vendor, not the vendor name. You can find internal IDs by exporting your vendor list from Lists > Relationships > Vendors, or by using a saved search.
For teams processing more than 50 invoices per week, SuiteScript (NetSuite's JavaScript-based API) provides a more scalable path. A SuiteScript 2.0 Map/Reduce script can read a CSV from the File Cabinet, create VendorBill records programmatically, and handle error logging. This eliminates the manual CSV upload step entirely but requires NetSuite development resources to set up. Lido's NetSuite export template formats your extracted data into the exact CSV structure described above. It also converts vendor names to internal IDs using a lookup against your NetSuite vendor list.
QuickBooks Desktop and QuickBooks Online are different products with different import capabilities. The distinction matters for document data import. QuickBooks Online is cloud-based and has a more limited native import. QuickBooks Desktop supports the IIF (Intuit Interchange Format) file, which is more flexible but more complex to construct.
QuickBooks Online does not have a native "import bills" feature in the same way NetSuite does. The most common approach is to import transactions through the Banking section using a CSV file, which creates transactions in the bank feed for review and matching. For direct bill creation, most teams use a third-party connector app (like Transaction Pro Importer or SaasAnt) that accepts CSV input and creates bills via the QuickBooks API. If you use one of these tools, your CSV needs: Vendor (exact name match to your QBO vendor list), Bill Date (MM/DD/YYYY), Due Date, Ref No (invoice number), Category (account name or number), and Amount.
The vendor name matching requirement in QuickBooks Online is strict. "ABC Supply Co." will not match "ABC Supply Co" (missing period) or "ABC Supply Company." This is where fuzzy matching becomes essential. Your extraction tool pulls whatever name appears on the invoice, which may not match your QBO vendor list exactly. You need a matching step that maps extracted vendor names to the exact strings in your vendor list before import.
QuickBooks Desktop supports IIF file import, which is a tab-delimited text file with a specific structure. IIF files use transaction type headers (TRNS for the header row, SPL for each split/line item, ENDTRNS to close the transaction). A properly formatted IIF file for a single bill looks like this:
!TRNS TRNSID TRNSTYPE DATE ACCNT NAME AMOUNT DOCNUM !SPL SPLID TRNSTYPE DATE ACCNT NAME AMOUNT MEMO !ENDTRNS TRNS BILL 01/05/2026 Accounts Payable Acme Corp -2000.00 INV-88012 SPL BILL 01/05/2026 Office Supplies 250.00 Q1 supplies SPL BILL 01/05/2026 Equipment 1750.00 Monitor purchase ENDTRNS
IIF files are powerful but unforgiving. The tab delimiters must be actual tab characters, not spaces. The header rows (lines starting with !) define the column structure. The TRNS row amount must be negative (representing the AP credit), and SPL row amounts must be positive (representing the debits). If you get the signs wrong, the bill will post backwards. Also note that QuickBooks Desktop expects the date in MM/DD/YYYY format with leading zeros, unlike NetSuite.
Lido's QuickBooks export template generates either a QBO-compatible CSV (for use with third-party importers) or a properly formatted IIF file for Desktop. The template handles vendor name matching, date formatting, and sign conventions automatically based on which QuickBooks version you select.
SAP is the most demanding ERP for data import, both in terms of the required fields and the specificity of the formatting rules. There are two primary import paths: IDoc (Intermediate Document) for automated integration, and flat file import through transaction codes for manual or semi-automated workflows.
For teams without an SAP integration developer, the most accessible import method is through transaction code MIRO (Enter Incoming Invoice) using the mass upload function, or through the LSMW (Legacy System Migration Workbench) tool. Both accept flat files, but the column structure and formatting requirements are strict.
A flat file for SAP AP invoice import typically requires these fields: Company Code (4-character code like 1000), Vendor Account Number (10-digit SAP vendor number, left-padded with zeros), Invoice Date (YYYYMMDD format with no separators), Posting Date (YYYYMMDD), Reference Document Number (the vendor's invoice number), Document Type (typically "RE" for incoming invoice), Currency (ISO code like USD, EUR), Header Amount (total invoice amount with period as decimal separator), GL Account Number (for each line item), Amount in Document Currency (for each line item), Cost Center (if required by your configuration), and Tax Code.
The date format requirement catches many teams. SAP uses YYYYMMDD with no separators or slashes. January 5, 2026 must be formatted as 20260105. The vendor account number must be exactly 10 digits, so vendor 12345 becomes 0000012345. The document type "RE" is the standard for vendor invoices, but your SAP instance may use custom document types. Check with your SAP administrator.
For automated integration, SAP uses IDocs: structured XML or flat-file messages that SAP processes through its ALE (Application Link Enabling) framework. The relevant IDoc type for AP invoices is INVOIC02 (or the newer INVOIC01 for some SAP S/4HANA implementations). An IDoc contains segments (E1EDK01 for header data, E1EDP01 for line items, E1EDP05 for conditions/amounts) with each segment having fixed-length fields. Building IDocs manually is impractical. This path requires middleware (SAP PI/PO, MuleSoft, or a custom integration) that transforms your extracted data into the IDoc structure and posts it to SAP's RFC endpoint.
Lido's SAP export template formats extracted data into the flat file structure expected by LSMW or MIRO mass upload. It converts dates to YYYYMMDD, left-pads vendor numbers to 10 digits, maps your vendor names to SAP vendor account numbers using a lookup table, and structures line items according to SAP's expected row format. For teams using the IDoc path, Lido can output the extracted data in a JSON structure that your middleware can transform into IDoc segments.
Microsoft Dynamics 365 Finance and Operations (formerly Dynamics AX) uses the Data Management workspace for bulk imports. The import format is typically Excel (XLSX), though CSV is also supported. Navigate to Workspaces > Data Management > Import, select the "Vendor invoices" data entity, and upload your file.
Required fields for Dynamics 365 vendor invoice import include: Invoice Account (the vendor account number in D365), Invoice Number, Invoice Date (format depends on your system locale, but YYYY-MM-DD is the safest for cross-locale compatibility), Currency Code, and at least one line with a Procurement Category or Item Number, Quantity, Unit Price, and Line Amount. D365 also requires a Number Sequence for the voucher, which is typically auto-assigned during import but can cause errors if the sequence is exhausted.
Dynamics 365 has a useful feature that other ERPs lack: import mapping templates. You can create a mapping template that defines which columns in your file correspond to which D365 fields, save it, and reuse it for future imports. This means you do not need to rename your CSV columns to match D365's exact field names. You map "Invoice #" to "Invoice Number" once and the mapping persists. The data validation rules still apply, though. Vendor accounts must exist, GL accounts must be valid, and dates must parse correctly.
Sage Intacct accepts CSV imports for AP bills through its import function under Accounts Payable > Bills > Import. Required fields include Vendor ID, Bill Date (MM/DD/YYYY), Due Date, Bill Number, GL Account Number, Amount, and Department (if your Sage instance requires dimensional tagging). Sage is relatively forgiving on date formats but strict on the Vendor ID. It must match the vendor record exactly.
For less common ERPs (Acumatica, Oracle NetSuite alternatives, Epicor, Infor), the principle is the same. Export a sample file from the ERP (most ERPs let you export existing transactions to see the expected format), match your extracted data columns to that structure, and validate a small batch before importing in bulk. The column headers, date formats, and vendor ID formats vary, but the workflow does not. Lido's extract-to-spreadsheet pipeline gives you a clean starting point that you can reformat for any ERP using computed columns.
The formatting challenges described above are predictable and repetitive. Every invoice has a date that needs reformatting. Every vendor name needs to be mapped to an ID. Every line item structure needs to match the ERP's expected layout. These are spreadsheet operations, and Lido handles them as part of the extraction workflow rather than as a separate manual step.
Date reformatting uses computed columns in Lido's output sheet. When you set up an extraction template, you specify your target ERP. Lido adds a computed column that reformats the extracted date into the correct format: M/D/YYYY for NetSuite, YYYYMMDD for SAP, MM/DD/YYYY for QuickBooks. The original extracted date is preserved in one column, and the ERP-formatted date appears in an adjacent column. If your ERP locale requires a different format, you can customize the formula.
Vendor name-to-ID mapping uses Lido's Smart Lookup feature. You upload your ERP's vendor list (a simple two-column table: vendor name and vendor ID) into a reference sheet. When Lido extracts a vendor name from an invoice, Smart Lookup fuzzy-matches it against your vendor list and returns the corresponding ID. "Acme Corp" on the invoice matches to "Acme Corporation" in your vendor list, and the output includes the vendor ID 4523 that NetSuite expects. This eliminates the most common import failure, vendor mismatches, without requiring exact string matching. For a deeper look at how this matching works, see our guide on fuzzy matching vendor names to your master list.
Line item restructuring is handled during extraction. Different ERPs expect different row structures, and Lido's extraction templates account for this. For NetSuite, the output uses the parent-child row format: header data on the first row, line items on subsequent rows with blank header fields. For QuickBooks IIF, the output uses TRNS/SPL/ENDTRNS row types with the correct sign conventions. For SAP, line items are structured with the header-level fields (company code, vendor number, document type) repeated or omitted according to the flat file specification.
The result is a single extraction configuration that produces an ERP-ready output file. You do not extract the data into a generic spreadsheet and then spend 30 minutes reformatting it for your ERP. The extraction and the formatting happen in one step. When you click export, the file is ready to upload to your ERP's import tool. For teams processing hundreds of invoices per week, this eliminates the manual transformation step entirely. Combined with automated data entry, the entire pipeline from PDF to posted transaction can run with minimal human intervention, typically just a final review step before posting.
NetSuite accepts CSV files for vendor bill import through its Import CSV Records tool (Setup > Import/Export > Import CSV Records). The CSV must use a parent-child row structure where the first row contains header fields (External ID, Entity, Tran Date, Tran ID) and subsequent rows contain line item fields (Account, Amount, Memo) with blank header fields. Dates must be in M/D/YYYY format without leading zeros, and vendors must be referenced by their NetSuite internal ID, not their display name.
QuickBooks Online does not have a native bulk bill import feature. You can import transactions through the Banking section as bank feed items, but for creating bills directly, you need a third-party importer app such as Transaction Pro Importer or SaasAnt. These tools accept CSV files and create bills via the QuickBooks API. Your CSV needs the vendor name (exact match to your QBO vendor list), bill date in MM/DD/YYYY format, reference number, category or account name, and amount for each line item.
SAP requires dates in YYYYMMDD format with no separators, slashes, or dashes. January 5, 2026 must be formatted as 20260105. This applies to both the Invoice Date and Posting Date fields. This format is used consistently across flat file imports, LSMW uploads, and IDoc messages. Using any other date format — including ISO 8601 with dashes (2026-01-05) — will cause the import to fail.
Export your vendor list from your ERP as a two-column table (vendor name and vendor ID). Use a fuzzy matching tool to compare the vendor names extracted from your invoices against this list. Exact string matching fails frequently because invoice vendor names rarely match ERP records exactly — differences in abbreviations, punctuation, and capitalization cause mismatches. Lido's Smart Lookup performs this fuzzy matching automatically during extraction, returning the correct vendor ID for each invoice based on approximate name matching against your vendor master list.
The extraction step itself is the same regardless of your ERP — the tool reads the same fields (vendor, invoice number, date, line items, amounts) from the document. What changes is the output formatting: column headers, date formats, vendor ID format, and line item row structure. In Lido, you set your target ERP once in the extraction template configuration, and the output formatting adjusts automatically. If you switch ERPs or need to output for multiple ERPs, you can duplicate the template and change only the output format settings without reconfiguring the extraction rules.
%20(1).svg)
