Semi Structured Data Explained with Examples
Learn what semi structured data is, see real examples, and discover how to parse it for bank statements and transactions.
You download a bank statement, open the PDF, and it looks tidy enough. The dates line up, the amounts sit in rows, and the total at the bottom feels like it should drop straight into Excel. Then the copy-and-paste job starts to fall apart, columns shift, credits and debits land in the wrong places, and a few transactions split across lines as if the file changed its mind halfway through.
That frustration is exactly where semi structured data lives. It carries real organization, but not the kind that stays obedient when we try to force it into a rigid table. For finance teams, that distinction matters because bank statements, invoice emails, ERP exports, and many web-delivered reports often look structured at first glance, then behave unpredictably once we try to process them.
Table of Contents
- The Bookkeeper and the PDF That Would Not Cooperate
- What Semi Structured Data Actually Means
- Semi Structured Data Examples You Already Know
- Parsing Strategies That Turn Messy Files Into Tables
- Why Bank Statements Are a Textbook Case
- Extracting Transactions From PDF Statements
- Governance, Schema Drift, and Reconciliation Checks
- Bringing It All Together for Finance Teams
The Bookkeeper and the PDF That Would Not Cooperate
Maria, a bookkeeper, opens a monthly PDF statement from her business bank and sees what looks like a clean ledger. The page has dates, descriptions, and amounts in neat rows, so she highlights a block and pastes it into Excel, expecting a quick cleanup. Instead, one vendor payment lands in the wrong column, a debit appears as a positive amount, and a few lines break across page boundaries in ways that make the month harder to reconcile.
She checks another statement from the same bank and finds a different template. The bank's support team tells her the layout can vary by branch and product, which explains why the file feels orderly but refuses to behave like a standard worksheet. That tension is the heart of semi structured data, there's structure in the file, but the structure isn't fixed enough to trust blindly.
Why the file feels organized and inconsistent at the same time
A bank statement is not free-form prose. It has repeated labels, visible rows, and predictable financial content, so we know where to look for dates, descriptions, and balances. But the document doesn't guarantee that every statement will use the same field names, the same spacing, or even the same visual layout.
For accountants, that means the problem isn't reading data. The problem is deciding which parts of the file are stable enough to extract and which parts need interpretation. That's why PDF statements sit so naturally in the world of semi structured data, they contain structure, but they don't submit to one universal schema.
Practical rule: if a file has repeating anchors like dates or field labels, but the layout shifts across sources or periods, treat it as semi structured data first.
The useful mental shift is simple. We stop asking, “Why won't this PDF act like a spreadsheet?” and start asking, “What structure does this file carry, and where can we safely read it?”
What Semi Structured Data Actually Means
Structured data, unstructured data, and semi structured data sit on a spectrum. Structured data is the easiest to picture, every row in a customer table has the same columns, and the schema tells us exactly what belongs where. Unstructured data sits at the other end, think contract text, email bodies, or free-form notes with no consistent field layout.
The middle ground is the important part
Semi structured data sits between the two. It has internal clues such as tags, keys, headers, or repeating patterns, but it doesn't force every record to look identical. A parser can still find fields, yet it has to tolerate missing values, reordered keys, optional sections, and nested content.
A spreadsheet analogy helps. In a clean workbook, every row uses the same columns and every record follows the same template. In semi structured data, the workbook still has headers or markers, but one row might include extra detail, another might omit a field, and a third might nest more information inside one cell or tag.
What makes a file semi structured in practice
Think of three common anchors. JSON uses keys like date, amount, or merchant, XML uses tags like <Transaction>, and CSV often uses a header row to signal column meaning. None of those formats guarantees the same exact shape across every file, but each gives software enough structure to extract useful fields.
That's why semi structured data is so practical for finance work. We don't need every source to look identical, we need the source to contain enough order that extraction is possible without hand-keying every line. The trade-off is that the parser must be flexible enough to survive missing columns, shifted headers, and nested details that appear only in some records.
The right question isn't whether the data is messy. It's whether the mess still has readable patterns.
Semi Structured Data Examples You Already Know
JSON is the easiest example to recognize in modern finance systems. A payment or transaction record might include an amount, a merchant name, and a status, while another record adds card type, location, or reference text. The structure comes from the keys, not from every row having the same exact set of values.
XML shows the same idea in a more verbose style. Older banking integrations often wrap each transaction in tags, and the tags tell us what each field means even when the record contains optional elements or repeated blocks. The file is not rigidly tabular, but it still gives us anchors for parsing.
CSV seems simpler, yet it can still be semi structured when real-world exports get inconsistent. One statement may include a Balance column, another may not, and a branded header might sit above the actual table so the parser has to ignore the first few lines before reaching usable data. Email headers also fit the pattern, because fields like From, To, and Subject are structured while the message body remains free-form.
| Format | Structural Anchor | Finance Example |
|---|---|---|
| JSON | Key names | Payment gateway transaction payloads |
| XML | Tag pairs | Legacy bank feed exports |
| CSV | Header row and delimiters | Downloaded statement exports |
| Header fields | Invoice notifications and remittance emails |
What stays consistent across all four examples
Each format gives the software a place to start. The parser can look for keys, tags, headers, or header fields, then build a useful record from the surrounding content. What changes is the level of consistency, and that's why finance teams need different parsing habits for different sources.
The unifying trait is simple. Structure exists, but it isn't guaranteed to look the same every time a new file arrives. That's what makes these formats easy to exchange and harder to govern.
Parsing Strategies That Turn Messy Files Into Tables
A bank statement can look tidy on screen and still be hard to parse. The file may expose labels, line breaks, or repeated blocks, but the layout can shift just enough to break a fixed import. That is why the parsing method has to match the kind of variation you see in finance files.
Rule-based parsing is the simplest place to start. If the source stays stable, fixed positions, delimiters, or known labels can move fields into columns. That works well for repeatable exports and text-heavy feeds, but it depends on the template staying put.
Pattern matching handles a different problem. A regular expression can pull a date, amount, or reference code from a line like 12/05 PURCHASE 45.67 CRD-9921, which helps when the text follows a consistent pattern but not a fixed table. It gives more flexibility, though it still expects the source to behave enough like the last file to match cleanly.
When the layout changes from file to file, schema inference helps. The parser inspects repeated tags, headers, or keys and builds a column map from what it sees. That suits different banks or vendors with slightly different layouts. For harder cases, ML-assisted extraction can read unfamiliar formats and flag low-confidence fields for review.
Practical rule: start with the simplest method that can survive the source you actually receive, not the source you wish you received.
A finance team can use the trade-offs to choose the right path:
- Rule-based parsing gives speed and predictability, but it breaks when templates drift.
- Pattern matching handles text variation well, but it can misread unusual formats.
- Schema inference adapts to changing fields, but it needs validation.
- ML-assisted extraction handles unfamiliar layouts, but human review still matters on edge cases.
For a deeper look at automated extraction, see our guide on automatic data extraction. For teams building repeatable workflows, a tool like autobankstatement converts PDF bank statements, including scanned and password-protected files, into CSV or Excel/XLSX, with bulk upload, files up to 25 MB, free guest preview before payment, 24-hour download access for registered users, and uploads deleted automatically within 24 hours. It gives finance teams a way to turn a document that resists copy-paste into something they can review and reconcile.
Why Bank Statements Are a Textbook Case
A month-end statement can look tidy enough to invite spreadsheet thinking. The trap appears when one bank labels the columns Txn Date, Description, and Amount, while another uses Date Posted, Details, and separate debit and credit fields. A PDF may also show a neat grid on one page and split a single transaction across two lines on the next.
The same financial event can appear in different shapes
A fee, a reversal, or a multi-currency line can change the layout again. One statement may show a negative amount, another may place the sign in a different column, and a third may relabel the same transaction after a platform change. That is why bank statements are a clear example of semi structured data in daily reconciliation work, the content is familiar to accountants, but the shape is not fixed.
| Field | Bank A | Bank B | Bank C |
|---|---|---|---|
| Date | Txn Date | Date Posted | Posting Date |
| Description | Description | Details | Narrative |
| Amount handling | Single amount column | Separate debit and credit columns | Mixed sign conventions |
A bookkeeper sees the transaction. A parser has to infer where that transaction starts, where it ends, and which column means what. That gap is the whole problem.
How the variation maps to parsing trouble
Variable headers break fixed-position rules. Inconsistent date formats make pattern matching less reliable. Layouts that mix text with scans or images push teams toward OCR and human review. For more on handling these files, see our guide on bank statement PDFs.
That is why statement extraction feels harder than it should. The source is readable to a person, but only partly stable for software.
The practical lesson is to treat bank statements as semi structured inputs from the start. Once you do that, the extraction plan becomes clearer. You stop asking for a perfect table and build a process that can handle layout drift, then reconcile the results against the ledger.
Extracting Transactions From PDF Statements
The first step is deciding what kind of PDF we have. Some statements contain selectable text, which means the transaction rows can be extracted directly, while scanned statements need OCR to turn page images into machine-readable text. Financial document tools commonly extract transaction rows, amounts, and balances from PDFs, scans, or images before exporting to spreadsheet formats such as CSV or Excel, which is why OCR is a standard part of the workflow. Financial bank statement OCR overview
A practical extraction flow
We usually start by locating the transaction block. Header keywords such as date, description, or amount help the parser find the usable region, then row boundaries are detected using date anchors or repeated text patterns. If the file is password-protected, the password has to be supplied or the PDF must be opened before parsing, because the extraction step can't reliably read a locked file. Password-protected bank statement upload guidance
After that, the output needs to serve the people who will review it. CSV is useful for downstream bookkeeping systems, XLSX works well for human review, and bulk processing matters when multiple accounts or multiple statements are involved. For uploads, file-size limits can be tight enough that statements need splitting or compression before submission, with examples in the source set ranging from 10 MB per file to 60 MB per file in different workflows. Document upload size limits across workflows
What to verify before trusting the export
The balance check is essential.
Practical rule: verify that opening balance + credits minus debits = closing balance before anything reaches the ledger.
That check catches extraction mistakes, sign-convention issues, and rows that were dropped during parsing. OCR can read the file, but reconciliation tells us whether the output is usable.
For teams that need a workflow reference, the same extraction logic is covered in a practical overview of OCR in banking, which fits naturally beside the earlier parsing choices and the balance check that follows every batch.
Governance, Schema Drift, and Reconciliation Checks
The hard part is not just extracting one good file. It's surviving the next file when the bank changes a label, inserts a new transaction type, or subtly alters the PDF layout during a product update. That slow erosion of assumptions is schema drift, and it shows up as missing fields, merged rows, broken date parsing, or balance columns that no longer line up the way they did last month.
What to check on every batch
Finance teams need a small set of gates that run every time a statement lands. The exact checks matter less than the consistency of the habit.
- Row count review. Compare the number of extracted transactions with what the statement visually suggests is present.
- Mandatory-field checks. Confirm that date, amount, and balance fields are populated where expected.
- Date-format consistency. Watch for a bank switching from one date style to another midstream.
- Duplicate detection. Catch repeated rows before they hit the reconciliation.
- Sign-convention review. A refund can appear as a negative debit, so the parser has to handle direction carefully.
A common failure mode is a file that still looks clean but now means something different. A renamed column can break downstream mapping without triggering a visible error, which is why governance has to include review, not just parsing. The same applies to statement cycles, because bank releases can introduce new layouts without changing the core business event.
Why the review cadence matters
Governance is not a one-time setup. It's a recurring control that tracks how external files change over time and how those changes affect the ledger. If the balance identity fails or a field starts drifting, the batch should be flagged for review before anyone treats it as final.
Bringing It All Together for Finance Teams
A finance team opening a PDF bank statement is handling semi structured data, even if the file looks tidy at first glance. The dates, amounts, balances, and memo text usually follow a pattern, but that pattern can shift just enough to break copy-paste or a simple import rule. That is why the practical goal is not to force every source into one perfect table, but to build a process that can read variation and still support reconciliation.
A practical decision rule
A stable source can start with rules and regex. Variable headers or layouts call for schema inference. High-volume or unfamiliar formats often need ML-assisted extraction, plus human review on the fields that drive the ledger.
The point is to match the method to the file. A bank statement that changes column labels midstream needs different handling from a fixed ERP export, just as a scanned statement needs more help than a digital one. If the source changes and the parser does not, the failure may look quiet while the downstream mapping is already off.
Flexibility saves setup work, but it also creates maintenance if teams do not validate, version, and watch for drift. Finance teams that build those controls early usually spend less time chasing broken imports and more time reconciling actual business activity.
The best extraction process is the one that keeps outputs stable while the source keeps changing.
If your reconciliation work is slowed by PDF statements that resist copy-paste, autobankstatement can automate the extraction. It handles digital, scanned, and password-protected files, converting them to CSV or Excel with bulk upload and built-in data controls. See how it fits your workflow at autobankstatement.
Convert your next statement in minutes
Upload a bank statement PDF — digital, scanned, or password-protected — preview the extracted table, and download clean CSV or Excel.