14.2 Structured vs Unstructured Data and the Analytics Process

B4c and B4d: know the data, then run the steps in order

Quick Answer: B4c asks you to explain data types, including structured and non-structured (commonly called unstructured). B4d asks you to explain the data analytics process: defining objectives, obtaining relevant data, normalizing data, analyzing data, and communicating results — in that order. Hygiene, completeness, and joining keys live inside obtain-and-normalize. The classic trap is analyzing before you have an audit question.

Chapter 11.2 used data analysis as a survey source: exception scans that aim later tests. This section is the process you follow whenever analytics will support engagement work. Chapter 13 is which tools might run the query. Chapter 15 is ratio, variance, trend, and benchmarking review. Do not import those catalogs into a B4c–d item. GIAS Standard 14.1 still requires information that can be analyzed; B4d is how that analytic work is sequenced.

Structured versus non-structured data

Structured data sits in predefined fields: tables, columns, data types, keys. ERP invoice registers, payroll registers, user-access lists, general-ledger extracts, and a well-designed warehouse table are structured. Once keys are clean you can filter, join, and total them.

Non-structured data is the syllabus wording. Most shops say unstructured. There is no reliable field layout: contracts in PDF, emails, chat, images of bills of lading, recorded calls, board minutes, policy wikis, free-text ticket comments. Meaning lives in the language or the picture, not in column D.

Semi-structured sources (JSON payloads, XML invoices, application logs, an email with headers plus a free-text body) sit between. The exam's official pair is structured and non-structured, so classify by whether you can already treat it as fields. A PDF invoice that an OCR job has already turned into vendor, date, and amount is structured for that test; the original PDF is still non-structured evidence you may need to inspect. A keyword search of 400 contracts is not a complete structured population; it is a text pass over non-structured files (Section 14.3).

Internal audit uses both on the same objective. Duplicate-payment work is mostly structured (register plus vendor master). Whether the contract allowed that payment term is non-structured until you mine or read the clause. Choosing only the easy table is how you miss the right.

Board minutes stored as a PDF do not become structured because they are official. Files do not become structured because they landed in the workpaper system. Structure is schema, not prestige or storage location.

The analytics process — five steps, in order

The 2025 list is five steps. The exam will punish skipping the first.

1. Defining objectives. Write the audit question the analysis must answer, tied to engagement objectives and evaluation criteria. Examples: Are there exact duplicate vendor-invoice-amount payments in Q1 for in-scope company codes? Which user IDs both changed a vendor bank account and released a payment? Is this extract complete against the AP subledger? If you cannot say what decision the output will support, you do not have an objective. You have a fishing trip. Defining objectives is not the same as Section A's engagement objectives, but it must serve them. Run analytics on AP is not a question.

2. Obtaining relevant data. Relevant means the population, period, fields, and grain that match the question. Request the invoice register for the scoped company codes and the posting-date period, including voids, parks, and reversals on purpose — included or excluded with a reason, not because the export button omitted them. Obtain authorization and a repeatable extract: query saved, parameters screenshot. Then test information produced by the entity (IPE): record count and dollars to the subledger or process file the walk-through used; a handful of lines to source for vendor, amount, and date. Chapter 11.2 already taught you not to scan garbage in the survey. B4d makes obtain a named step so eagerness to analyze is not an excuse to skip it.

3. Normalizing data. Make fields comparable before you join or score. Normalization is hygiene, not a finding:

• Dates to one timezone and one meaning (invoice date versus posting date versus baseline date).
• Currency to one unit, or as-posted amounts plus a documented FX source — not a silent mix of USD and local.
• Vendor names and IDs to the same grain (strip Inc., leading zeros; know DBA versus legal name).
• Amounts to one sign convention (reversals as negatives, not a second positive that inflates volume).
• Text trimmed; encoding fixed so Müller does not split from Muller unless you intend that split.
• Duplicate rows that are extract artifacts (the same invoice pulled twice because of a many-to-many join) removed. That is not the same as a duplicate payment condition. Hygiene first; condition second.

Joining keys are the fields that must identify the same real-world thing in two files: vendor ID, invoice number, employee ID, PO number, user ID. If AP uses vendor number and the bank file uses IBAN, you need a crosswalk, not a hopeful name match. A fuzzy name join is a method you document, not a silent default. Wrong keys manufacture false duplicates and false comfort. Display names that three people share are not a user-ID key.

Completeness belongs to obtain and normalize. If the question is the Q1 population and the extract is 3,870 rows against a 4,200-invoice subledger, stop. Find parked items, intercompany, or company code 200. Analyzing the 3,870 because we have to start somewhere is how you miss the plant that never loaded. Large is not complete.

4. Analyzing data. Only now apply the method that fits the question (Section 14.3). Sorts, matches, diagnostics, models — they all wait for a defined question and a clean, complete file. Analysis on a file you never reconciled is theater with decimals.

5. Communicating results. Tell a decision-maker what the analysis showed, with population, limitations, and what you still must test. A chart that lacks a question is decoration. This step is communication of analytic results during the engagement (Section C covers methods and stakeholders). It is not Part 3's final-report attribute list and not Chapter 15's finding elements (criteria, condition, cause, effect, significance). You can say: 18 exact duplicates, $612,000, file complete to the subledger, override IDs not yet inspected. You cannot skip to residual-risk acceptance language.

Worked example: vendor master joined to AP

Objective: Identify payments released after a bank-detail change by the same user ID in Q1.

Obtain: Vendor-master change log (who, when, old/new bank), AP payment register (who released, when, vendor, amount), HR termination list (leftover IDs). Reconcile payment dollars to the subledger.

Normalize: User IDs to the live directory (display names collapse three people). Bank fields to IBAN or account-plus-routing, not free text. Timestamps to posting timezone. Vendor ID as the join key, not vendor name.

Analyze: Join change-log to payments on vendor ID where change-user equals release-user and payment date is on or after the change date. That is a structured match serving an SOD question — not yet a fraud conclusion.

Communicate: 11 payments, $2.1 million, four user IDs; two IDs belong to terminated staff. Next: inspect whether those IDs were shared, and walk two items.

If the team had sorted the payment register by amount and started calling large items high risk, they would have skipped the objective, the join, and the terminated-ID story. That is the B4d trap in one motion.

Exam traps

• Analyzing before defining the audit question.
• Treating non-structured PDFs as a complete population because a keyword returned hits.
• Joining on names when a stable ID exists — or assuming IDs mean the same grain in both files.
• Calling extract-duplicate rows a duplicate-payment finding.
• Skipping completeness because the file is large enough.
• Jumping from a pivot to a Part 3 residual-risk memo, or answering B4d with a Chapter 15 current-ratio calculation.

The process is done when a reviewer can re-perform the extract from saved parameters, see the completeness tie-out, name the join keys, and read a result that answers the question you wrote in step 1.