Hi @NimaiAhluwalia
A good starting point is this: 837 is usually the wrong transaction set for invoices. In X12, the 837 is the Health Care Claim transaction set, used for submitting healthcare claims to payers, not general invoicing. For invoices, the common X12 transaction is 810 (Invoice), and in some client ecosystems the right answer may instead be EDIFACT INVOIC, Peppol BIS Billing, or a custom flat-file layout. So before you build anything, confirm the client’s required standard, version, and implementation guide.
If the client truly asked for X12 837, pause and verify whether they actually mean a healthcare claim workflow. X12’s own description says 837 is for health care claim billing and encounters, and their examples for 005010X222 are specifically professional healthcare claim examples.
The best design is not “PDF to EDI” directly, but a two-stage pipeline:
- extract PDF data into a canonical structured model,
- map that model into the target EDI transaction and validate it.
That keeps your extraction logic separate from your trading-partner-specific EDI rules, which matters because EDI formats are rigid and partner-specific implementation guides often add required segments, qualifiers, and code lists beyond the base standard. X12 notes that implementation guides are specific to a business purpose and version, which is why the mapping spec matters so much.
A practical architecture looks like this:
- Stage 1: Canonical invoice/claim model
Store fields like sender, receiver, invoice number, dates, line items, tax, totals, service codes, claim amounts, etc. in tables or JSON.
- Stage 2: Mapping layer
Translate those canonical fields into EDI segments and elements based on the client’s implementation guide.
- Stage 3: EDI generation
Assemble envelope segments plus transaction segments in the correct order.
- Stage 4: Validation
Validate required segments, code values, lengths, segment counts, control numbers, and trading-partner rules.
- Stage 5: Output
Write the final interchange as plain text with the correct delimiters and terminators.
That approach is much safer than trying to generate EDI straight out of Power BI transformations.
For the actual file generation, think in terms of segments and envelopes. In X12, you do not just dump rows into a .txt file. You must build the interchange structure correctly, typically including ISA/GS/ST ... SE/GE/IEA, with the transaction’s business segments in the middle. The exact middle content depends on whether you are generating an 810, 837, or something else. The X12 examples are useful for seeing the expected shape of a valid file.
For tools, a dedicated EDI library is usually worth it. In .NET, EdiFabric supports parsing, generating, validating, acknowledgments, and multiple standards including X12; its public examples specifically cover X12 and HIPAA flows. There are also lighter/open-source options like EdiEngine and older packages such as OopFactory.X12, but those may require more manual work and may not be as complete for validation or newer implementations.
Because you mentioned Power BI: Power BI is fine for extracting and shaping data, but it is not the ideal place to author a production-grade EDI generator. Microsoft’s Power BI/Fabric guidance is centered on prep, modeling, export, and orchestration—not EDI serialization. A stronger pattern is:
- use Power Query / Dataflows / Fabric to extract and normalize the PDF data,
- hand off the structured output to a small service or script,
- generate and validate EDI there,
- then store or transmit the finished file.
Best practices that save a lot of pain:
- Get the exact trading partner spec first: standard, version, required loops/segments, qualifiers, delimiters, and sample files.
- Build from a known-good sample EDI and map backward.
- Keep a canonical data model separate from EDI-specific rules.
- Add validation before output and reject records with missing mandatory fields.
- Maintain control numbers and segment counts carefully.
- Test against multiple realistic invoices/claims, not just one happy-path sample.
- Plan for partner variations; even within the same X12 transaction, implementations differ by receiver.
So my honest recommendation is:
- First confirm whether the client really needs 837 or actually needs 810 or another invoice format.
- Then build a small conversion service outside Power BI using a dedicated EDI library.
- Use Power BI/Fabric only for the extraction and shaping step.
If you want, I can sketch a concrete end-to-end design for either PDF → canonical JSON/table → X12 810 or PDF → canonical JSON/table → X12 837, with example segment mapping.
Did I answer your question? Mark my post as a solution! Appreciate your Kudos !!
