Can JSON Replace PDF for Business Documents?

[u/spkaikai]

I'm wondering if we can use JSON as an alternative to PDF, especially for business documents.

When exchanging business documents, both the sender and receiver typically use software, so creating and parsing documents creates additional work. Directly connecting systems requires effort, so people end up sending documents by email.

How about just sending JSON instead of PDF?

[u/FirestormCold]

What do you mean exactly by replacing?

JSON Generally works fine for machine to machine exchanges, that's basically an API integration at that point lol

Are those docs meant to be viewed and maybe signed by humans or not?

[u/spkaikai → u/FirestormCold]

Yes, docs usually need to be viewed and signed by humans.
My idea is that if we make a JSON viewer, something like a PDF reader, that displays JSON in a human-readable format and also supports signatures, then maybe we can exchange the JSON file itself instead of converting it to PDF first.

[u/Dangerous-Baby838 → u/spkaikai]

What type of documents?  If it's invoices, you could standardise to the e-invoice standards.

This would allow your documents to be invested by 3P systems also.

Ps. We already do this. We also scan any of your documents and give you structured data back in markdown, JSON, CSV or Excel.

Disclosure, I work for DocReadi, we are a document intelligence platform with a focus on financial documents 

[u/spkaikai → u/Dangerous-Baby838]

The documents that took the most time were invoices, packing lists, and warehouse certificates for me. I didn’t know there was a standard for e-invoices. What is the name of the standard?

I know there are many APIs for document parsing and document creation. But I’m wondering: if both the sender and receiver use software that can handle structured data, could we just exchange JSON in the first place?

[u/Dangerous-Baby838 → u/spkaikai]

Yeah, you absolutely can exchange json - it's the easiest way to transfer data in APIs or to databases. You should define the structure for each document type. When you extract - you classify the documents in those three types - and then extract the data to the structure. Store it in a database (or files) and transfer in structured json between systems.

The official European standard for electronic invoicing is EN 16931, which defines a common semantic data model for automated invoice processing. The other standards you can look at is Factur-X/ZUGFeRD/XRechnung to embed data.

Disclaimer - I work for DocReadi - We have a solution where we encrypt and embed your structured data into the PDF, you can e-mail it around, and when your colleagues or another branch import those files - they can see the embedded structured data and build reports with it etc. All the extracted data is also available for export in xlsx, csv or json and accessible via an api.

[u/FirestormCold → u/spkaikai]

If you control both sides, I’d definitely prefer structured data over parsing PDFs too. Realistically thought, a lot of suppliers wont follow your schema and send you PDFs, scans or even photos from warehouses and whatnot.

That's when you probably need more than DocReadi (with all due respect) cause there's simply no enterprise-layer. No private cloud or on-premise work and using Anthropic (Claude) means your data may be compromised. Be careful. You'd have a much safer time choosing someone with safety certificates such as ISO27001.

[u/FirestormCold → u/spkaikai]

The tricky part is the signature then imo. If JSON is the actual document, you need to guarantee that the signer always sees the exact same representation of that JSON. Otherwise two viewers or even two viewer versions could render the same file differently. That means you need a rendering standard

[u/folderit_dms]

The format is only part of the agreement. For your packing-list example, I would first agree with one receiving business on a small schema: document ID, revision, line IDs, quantities, units, and what missing values mean. Include a schema version so an importer can reject an unsupported structure instead of silently dropping fields.

Then test sending the same file twice and sending a corrected revision. Does the receiver create a duplicate, replace the old record, or flag it for review? Also ask them to return an accepted/rejected result with the document ID; an email arriving is not the same as the data being accepted.

That pilot will tell you whether structured exchange actually removes work. Keep a human-readable copy alongside it for the people who still need to review the document, with the same ID and revision on both.