PDF Extraction, EDI Parsing, and the File Formats B2B Clients Actually Send

The problem: B2B data comes in every format imaginable

If you build B2B software, you have heard the same story from your enterprise clients. They cannot send you a clean CSV. Their ERP exports fixed-width text files. Their procurement system generates EDI X12 850 purchase orders. Their finance team sends PDF invoices. Their compliance department shares XML reports. Their HR team exports XLSX workbooks with six sheets, three of which are blank.

This is not an edge case. This is the default state of enterprise data exchange. According to industry estimates, fewer than 30% of B2B file transfers use CSV as the primary format. The rest is a mix of legacy formats, industry-specific standards, and whatever export button the source system happens to offer.

Most file import tools were built for CSV. Some support Excel. Almost none handle PDF table extraction, EDI parsing, or fixed-width files. This guide walks through how each of these formats actually works, what it takes to parse them, and how to design an ingestion pipeline that keeps working when a client's export format changes.

The three tiers of B2B file formats

It helps to group the formats your clients send into three tiers, because each tier requires a fundamentally different parsing approach.

• Tabular text and spreadsheets (CSV, TSV, XLSX, XLS): Rows and columns, but with messy variations: delimiters, encodings, merged cells, multiple sheets, header rows buried under titles. Parseable with a good general-purpose pipeline.
• Hierarchical formats (JSON, XML): Structured and self-describing, but nested. Records have to be located and flattened into rows before they can be mapped to a schema.
• Specialist formats (PDF, EDI, fixed-width): Formats that carry no self-describing tabular structure at all. Each needs dedicated, format-specific tooling before the data can enter a normal pipeline.

How PDF table extraction works

PDF is the most challenging format because it is a presentation format, not a data format. Tables in PDFs have no underlying structure. They are visual arrangements of text on a page. When an enterprise client sends a PDF invoice, a compliance certificate, or a bank statement, the data you need is locked inside a format designed for printing, not for parsing.

Traditional PDF parsers rely on text extraction, which produces an unstructured stream of characters with no concept of rows, columns, or tables. That approach fails for any document with meaningful tabular structure. Modern PDF extraction tools use AI-based layout analysis instead, and the pipeline generally looks like this:

1. Table detection: A layout model analyzes the visual structure of each page and identifies regions that contain tabular data, even when tables have no visible borders or grid lines.
2. Structure recognition: Within each detected table region, the model identifies column boundaries, header rows, and data rows. Merged cells are detected and their values attributed.
3. Data extraction: Text content is extracted from each cell and organized into rows and columns, producing tabular data from what was previously a visual layout.
4. Human review: Because extraction is probabilistic, serious workflows always include a preview step where a person verifies the output before it enters downstream systems.
5. Export to a structured format: The confirmed table is written out as CSV, JSON, or XML so that a standard ingestion pipeline can take over.

The practical takeaway: PDF extraction is a dedicated preprocessing step, not something to bolt onto a general import pipeline. Extract to a structured format first, then map, validate, and deliver through the same pipeline as every other file.

How EDI parsing works

EDI (Electronic Data Interchange) has been the standard for B2B document exchange in supply chain, healthcare, and retail for decades. Despite its age, EDI is not going away. The global EDI market was valued at $41 billion in 2024 and is projected to grow to $91 billion by 2032. If your product operates in any of these industries, you will encounter EDI.

The challenge with EDI is that it was designed for machine-to-machine communication in the 1970s. An EDI X12 document is a stream of segments separated by tildes, with elements separated by asterisks. There are no labels, no headers, and no self-describing structure. Parsing EDI requires knowledge of the specific transaction set schema to know which segment contains which business data.

The transaction sets you will actually see

• 850 (Purchase Order): The most widely used EDI document. Contains buyer information, shipping details, and line items with quantities, prices, and product identifiers.
• 810 (Invoice): The supplier's invoice in response to a purchase order. Contains invoice amounts, line item details, tax information, and payment terms.
• 856, Advance Ship Notice (ASN): Notifies the buyer that a shipment is on its way. Hierarchical data with shipment, order, and item levels.
• 834 (Benefit Enrollment): Used heavily in healthcare for enrolling members in benefit plans. Member demographics, coverage information, and effective dates.
• EDIFACT (ORDERS, INVOIC, DESADV): The international equivalents, used extensively in European and Asian supply chains.

In practice, teams that receive EDI run it through a dedicated EDI translator: a tool whose whole job is to turn X12 or EDIFACT streams into labeled, structured records, usually CSV, XML, or JSON. Once the translator has produced structured output, the data can flow through the same mapping and validation pipeline as any other file. Trying to hand-parse EDI inside application code is how teams end up with a brittle integration that only one engineer understands.

Fixed-width files

Fixed-width (positional) files are still used by banks, insurance companies, government agencies, and mainframe systems. Each field occupies a specific character range in each line: characters 1 to 9 are the employee number, 10 to 39 the name, and so on. There are no delimiters at all.

Parsing fixed-width files is mechanically simple but operationally fragile: it depends entirely on a written spec from the sender, and the spec drifts. The reliable pattern is the same as with PDF and EDI: convert to a delimited format at the boundary (a small script or the sender's own alternative export), then let a schema-validated pipeline catch every drift the moment it happens instead of three weeks later in your database.

What FileFeed supports today

FileFeed focuses on the formats that carry the large majority of recurring client file feeds: CSV, Excel, TSV, JSON, and XML. Every one of them feeds into the same pipeline: AI-assisted field mapping that you review and approve, schema validation on every row, built-in transform functions, and delivery as clean JSON over signed webhooks, with outbound SFTP export back to clients when you need it.

• CSV and TSV: Any common delimiter (comma, tab, pipe, semicolon), quoted fields with embedded delimiters and newlines, and standard encoding quirks like BOM headers from Excel exports.
• Excel (XLSX and XLS): Multi-sheet workbooks, merged cells, and header rows that do not start on line one. See how multi-sheet table detection works in practice.
• JSON: Flat or nested structures, with arrays unwrapped into rows for mapping.
• XML: Record extraction from configurable row elements, common in healthcare, government, and legacy enterprise systems.

Files arrive over SFTP or email: FileFeed-hosted SFTP, a connection to your client's own SFTP server, or email attachments from allow-listed senders. To be direct about the boundaries: FileFeed does not parse PDF, EDI, or fixed-width files natively today. If those formats are the core of your workload, you need a dedicated extraction or translation step in front of your pipeline.

How to handle PDF and EDI alongside a file pipeline

The architecture that works in practice is a two-stage pipeline: a format-specific front end, and a schema-validated processing layer behind it.

1. Translate at the boundary: An EDI translator or PDF extraction tool converts the specialist format into CSV, JSON, or XML. This is the only stage that needs format-specific knowledge.
2. Drop the output on SFTP: The translator writes its structured output to an SFTP folder, the same way any other client system delivers files.
3. Process like any other feed: From there, FileFeed picks the file up, maps columns to your schema, validates every row, applies transforms, and delivers clean JSON to your API. Your application never knows the data started life as an EDI 850 or a PDF invoice.

How common import tools compare on format support

• Flatfile: Supports CSV and Excel through an embeddable importer. No XML, no SFTP-first recurring feeds as the primary model.
• OneSchema: Supports CSV and Excel, focused on the embeddable import experience for spreadsheet-like files.
• Couchdrop: Handles file transfer (SFTP, cloud storage routing) but does not parse files at all. No schema validation, no mapping, no transformation. It moves files from point A to point B without processing them. See the full FileFeed vs Couchdrop comparison.
• Custom code: You can build parsers for any format, but each one takes engineering time. Maintaining parsers across hundreds of client configurations is a full-time job for a team.
• FileFeed: Parses CSV, Excel, TSV, JSON, and XML, and pairs parsing with the processing layer the tools above lack: AI-assisted mapping, schema validation, built-in transforms, and delivery over signed webhooks and outbound SFTP.

Real-world scenarios

Healthcare and government: XML filings to clean records

A compliance platform ingests regulatory filings that arrive as XML documents with deeply nested element structures. FileFeed extracts records from the configured row elements and maps them to the platform's internal schema. When the same data arrives from a different agency as a CSV export, the same target schema and validation rules apply. No new code.

HR platforms: multi-sheet Excel exports from every HRIS

Clients export employee data from Workday, BambooHR, ADP, or a custom system, each with its own column names, sheet layouts, and date formats. FileFeed detects the data sheet, auto-maps columns to the target schema for review, validates every row, and delivers uniform JSON to the platform's API.

Supply chain: EDI behind a translator, everything else direct

A marketplace receives supplier catalogs as CSV and Excel from most partners, and EDI 850 documents from two large retailers. The EDI feeds go through a translator that outputs CSV to an SFTP folder; every feed, translated or direct, then flows through the same FileFeed pipeline, the same validation rules, and the same webhook into the order system. This split is the core of a maintainable supply chain data onboarding setup.

Getting started

If your clients send recurring CSV, Excel, TSV, JSON, or XML feeds and every new client currently means custom mapping code, Automated FileFeeds replaces that per-client engineering with a pipeline your CS team can configure. And if part of your workload is PDF or EDI, the two-stage pattern above lets you keep one processing layer for everything instead of a parser per client.

Enterprise data exchange is messy. File formats are diverse, encodings are inconsistent, and every client has their own way of exporting data. You do not fix that by hand-writing another parser. You fix it by putting a schema-validated pipeline behind every feed, and dedicated translators in front of the few formats that need them.