Recorded Identity and Workbook Chronology

XLSX Metadata and Document Properties

Separate editable author and date fields from application fingerprints, remembered paths and independently recorded delivery events.

  • Court qualified expert witnesses
  • Former law enforcement forensic examiners
  • Hash verified chain of custody
  • Nationwide support for attorneys and clients

Home › Digital Evidence Authentication › Excel Spreadsheet Authentication › XLSX Metadata and Document Properties

Quick Answer. XLSX metadata records document properties and application details, not an authenticated history of every edit. Examiners read core.xml, app.xml, custom properties and workbook attributes, then compare them with preserved attachments and external records. Creator names can be inherited, timestamps can be rewritten, and saved paths can identify an environment without proving who operated it.

Within Excel Spreadsheet Authentication, metadata supports questions about claimed preparation and chronology. It should be read alongside package structure and version comparisons. A property is a recorded statement inside the workbook. An independent mail server delivery or cloud version event is a different kind of record, and the two should not be given equal evidential weight.

Property locationdocProps parts hold core, application and custom fields.
Producer detailfileVersion can retain application and build attributes.
Path residueSaved absolute paths can identify a working environment.
Chronology anchorExternal version events test internal date claims.

Questions about XLSX property evidence

QuestionShort answer
Where are XLSX author properties stored?The core properties part, conventionally docProps/core.xml, can contain dc:creator and cp:lastModifiedBy. These are editable document fields, not authenticated login identities.
What does XLSX app.xml record?Application properties can include Application, AppVersion, company and workbook heading information. Availability and population vary by producer and save process.
What does XLSX fileVersion identify?The workbook fileVersion element can carry appName, lastEdited, lowestEdited and rupBuild attributes. Interpret these as producer compatibility and build details, not a complete operating system inventory.
Can XLSX metadata prove a creation date?The stored created property states a date written into the file. Corroborate it with acquisition, delivery or version records before using it to establish when the workbook existed.
What can x15ac:absPath reveal in XLSX metadata?It can retain an absolute folder path, including a Windows user directory. The path describes saved environment information and does not by itself identify the human editor.
Are XLSX custom properties reliable author evidence?They can contain useful project identifiers and workflow labels, but applications and users can set them. Verify important values against the system said to have supplied them.

Key terms defined

dc:creator

A core property recording the creator name string associated with the document, potentially inherited from a template or account profile.

cp:lastModifiedBy

The core property recording a last modifier name string, which is not a server authenticated identity assertion.

dcterms:created

The core creation date property, interpreted as recorded metadata rather than independently verified first existence.

AppVersion

An extended property describing the application version string written by the producer.

fileVersion rupBuild

A workbook attribute carrying build related information that can be compared across related files and known workflows.

x15ac:absPath

An extension element that can preserve an absolute folder path associated with the workbook environment.

Which XLSX properties describe identity and time?

Read the property parts through their package relationships. The conventional core part is docProps/core.xml. It can contain creator, last modifier, title, subject, description and creation or modification dates. Preserve exact strings and timestamp representations before normalizing them for comparison. Missing fields are findings about the supplied file, not evidence that an unknown editor deliberately removed them.

PropertyQuestion it supportsIndependent comparison
dc:creatorWhose profile name was recorded?Template and source workstation context
cp:lastModifiedByWhich modifier string survived?Version history and account activity
dcterms:createdWhat creation time is claimed internally?Earliest acquired delivery or backup
dcterms:modifiedWhat modification time was written?Preserved versions and save events
Custom project identifierWhich workflow label was retained?Project registry or export system

Inherited properties survive ordinary reuse

A workbook copied from a departmental template can preserve an old creator name and creation date. A person can then populate it with new transactions without changing those fields. Conversely, a conversion can replace the application name while preserving business cells. Ask how the organization creates workbooks before interpreting an old property as evidence of backdating.

Time fields require particular care. Preserve explicit UTC markers and offsets when present; do not silently apply the examiner's local timezone to an unqualified value. Compare like events: an internal modified date describes a recorded document property, while a message timestamp describes a communication event. A workbook can legitimately predate its transmission by months.

The authenticity workflow connects those observations to a disputed timeline. Metadata supplies hypotheses and comparison points, while acquired versions establish which content existed at those points.

An author name needs an independent identity anchor

We compare property strings with acquired messages, account events and earlier versions. This separates an inherited profile name from evidence that a particular account handled the workbook.

Request Confidential Consultation Call (833) 292 3733

How do application fingerprints and saved paths help?

The extended properties part, usually docProps/app.xml, records application related fields. The workbook itself can contain fileVersion attributes. Compare these layers together rather than expecting one field to encode a complete application history. Producers can preserve old fields, omit optional data or write compatibility values.

Recorded detailExample formAppropriate interpretation
ApplicationMicrosoft ExcelProducer label, subject to rewriting
AppVersionNumeric version stringRecorded application family detail
fileVersion appNamexlWorkbook application designation
fileVersion lastEditedCompatibility generation valueCompare with known producer behavior
fileVersion rupBuildBuild related attribute valuePossible environment fingerprint
x15ac:absPathC:\Users\Morgan\Documents\Accounts\Remembered folder context

A Windows folder is not a login audit

An x15ac:absPath value recording C:\Users\Morgan\Documents\Accounts\ is concrete evidence that this path string exists in the file. It can help locate related evidence or compare a claimed Linux export with a Windows save environment. It does not establish that Morgan personally edited the workbook. Shared workstations, copied profiles and retained paths are ordinary alternative explanations to test.

Do not contact a recorded network path or external location during initial inspection. Preserve the string, record its part and element, and pursue the resource through authorized collection. A path can reveal sensitive organization or user information; quote only the relevant portion in public exhibits and preserve the complete value in examination records.

Compare several known files from the asserted workflow

A single unusual version attribute is weak evidence of fabrication. Obtain genuine examples produced by the same export or template process when available. Compare application strings, namespace declarations, property population and workbook serialization. A consistent combination is more informative than an isolated field, but it still describes software behavior rather than an authenticated person.

How should metadata be tested against a chronology?

Build a chronology with separate columns for internal properties and external events. An acquired email attachment supplies content known to have been transmitted in that message. A cloud version can supply a prior workbook and a recorded account event. A filesystem modified time describes the acquired filesystem entry, which can change through copying or extraction. Keep these event types distinct.

Test a concrete backdating claim

Suppose a workbook claims a January creation date but contains transactions said to have been entered in April. That alone is consistent with reuse of a January template. Obtain the January attachment or backup and compare its actual worksheet content. If the April rows are absent there and present in a later version, the comparison establishes a content change between versions. The internal January date did not establish that those rows existed in January.

  • Record the precise internal field and literal timestamp.
  • Identify the external record and what event it actually documents.
  • Compare workbook content at each preserved point.
  • Explain any template, conversion or privacy removal behavior supported by evidence.

Report removed metadata without inventing motive

Document inspection features, exports and processing workflows can remove personal properties. A sparse core.xml is not automatically a sign of concealment. Determine whether the producing system routinely strips those fields and compare other files from that process. If the workbook was sanitized for production, obtain the native source or processing documentation when relevant.

Metadata should not be presented as a complete revision log. Most XLSX files do not contain an exhaustive record of authors, save events or cell editing times. A careful report quotes the actual field, identifies its part path, explains corroboration and states the resulting chronology at the resolution the records support.

Examine XLSX properties against external events

Extract properties without opening the workbook interactively. Preserve literal values before converting dates or grouping application fingerprints.

  1. Resolve property relationships. Locate core, extended and custom property parts from the package. Record missing parts and retained namespaces without assuming every optional property must exist.
  2. Capture identity and date strings. Export creator, last modifier, created and modified values with part paths. Keep original timezone notation alongside any normalized chronology.
  3. Read producer attributes. Inspect Application and AppVersion, then workbook fileVersion appName, lastEdited and rupBuild. Record actual values rather than assigning unsupported release dates.
  4. Collect remembered environment paths. Locate x15ac:absPath and other relevant path strings. Preserve them as data and do not activate network targets.
  5. Compare known workflow specimens. Use acquired files from the same template or export process to distinguish routine metadata patterns from unexplained differences.
  6. Anchor conclusions to preserved events. Compare native attachments and historical versions with server or account records. State what content is established at each independently recorded point.

What matters most

  • Literal property strings before date normalization or identity assumptions.
  • The difference between an internal date and an externally recorded event.
  • Template inheritance as an explanation for old creator fields.
  • Application fingerprints interpreted as combinations rather than isolated values.
  • Saved user folder paths treated as environment evidence, not personal attribution.

Common misconceptions

  • The XLSX creator field identifies the actual typist It records a name string and can survive copying, templates and profile reuse.
  • An XLSX modified property is a server timestamp It is stored inside the editable package and requires external corroboration.
  • A Windows username in absPath proves the editor The folder string can be inherited or shared and does not authenticate an operator.
  • Missing XLSX personal properties prove concealment Privacy inspection and ordinary processing can remove optional metadata.

When this applies, and when it does not

This applies when

  • Testing claimed workbook preparation dates
  • Comparing template and export fingerprints
  • Investigating recorded author mismatches
  • Building a chronology from preserved versions

This does not apply when

  • Attributing edits from property names alone
  • Treating metadata as an exhaustive revision journal
  • Dating a product release from an unverified build lookup

How Elite Digital Forensics helps

We separate document property assertions from independent event records and explain which identity, environment and timing inferences survive comparison with the acquired evidence. Our team is made up of subject matter experts in XLSX metadata analysis who reconcile workbook properties with file system, email, and server records.

About Elite Digital Forensics

Elite Digital Forensics is an independent digital forensics practice serving attorneys, paralegals, in house counsel, insurers, lenders, businesses, and individuals nationwide. Our team includes former law enforcement forensic examiners and court qualified expert witnesses in computer, cell phone, cloud, document, and multimedia forensics. Every engagement begins with a scoped plan, hash verified evidence handling, and a clear explanation of what the examination can answer.

Related Digital Forensics Resources

Limits and uses of workbook property analysis

Can XLSX metadata be edited without changing worksheet values?

Yes. Properties are separate package content. A property edit changes file bytes while leaving the business cells unchanged, so report those differences separately.

Why does XLSX metadata show a former employee?

The workbook may inherit a profile or template creator string. Compare earlier templates and account records before attributing current work to that person.

Does XLSX metadata reveal every application that opened it?

No. Saved fields can describe a producer or retained application details, but they do not provide a complete opening history.

Can XLSX custom properties identify an export job?

They can preserve a job label or identifier. Verify it against the originating system's records before treating the value as an authenticated export event.

Should an XLSX absPath be included in a public report?

Include only the portion necessary to explain the finding. Preserve the full string in examination records and consider privacy and protective order requirements.

How can XLSX metadata support a stronger date conclusion?

Combine it with acquired historical content and independently recorded delivery or version events. State which version existed at the evidenced time rather than relying on the internal property alone.

Test the recorded date against a real event

Provide the workbook with its original message or available version history. Those records let us evaluate the stored properties without confusing document assertions with independently observed chronology. As court qualified experts in spreadsheet metadata, we can explain any conflict between those dates in plain language.

Request Confidential Consultation Call (833) 292 3733

Primary sources and references

  1. Ecma International, ECMA 376, Office Open XML File Formats (also published as ISO/IEC 29500). Ecma International, ECMA 376
  2. Library of Congress, Sustainability of Digital Formats, XLSX Transitional (Office Open XML). www.loc.gov
  3. Microsoft Learn, Structure of a SpreadsheetML document. learn.microsoft.com
  4. Microsoft Support, Remove hidden data and personal information by inspecting documents, presentations, or workbooks. support.microsoft.com
  5. NIST Special Publication 800 86, Guide to Integrating Forensic Techniques into Incident Response. csrc.nist.gov
  6. Federal Rules of Evidence, Rule 901, Authenticating or Identifying Evidence. www.law.cornell.edu/rules/fre/rule_901

This content is for educational and informational purposes only and does not constitute legal advice. Elite Digital Forensics provides independent digital forensic services and expert witness testimony; we do not provide legal representation. Every case is fact specific; outcomes depend on the evidence, jurisdiction, and counsel. Retain qualified legal counsel for advice about your matter.

#DigitalForensics #ComputerForensics #CellPhoneForensics #ExpertWitness #DigitalForensicExperts #EliteDigitalForensics #ForensicInvestigation #CriminalDefenseForensics #XLSXMetadata #CoreProperties #WorkbookDates #ApplicationFingerprints #SavedPaths #VersionChronology

Assistant Icon Elite Digital Forensics Assistant
πŸ‘‹ Live Chat Now!
Free Virtual Consultation 24/7
Chat Now!

By submitting this form, you consent to be contacted by email, text, or phone. Your information is kept secure and confidential. Reply Stop to opt out at anytime.Β 

IMPORTANT: Please remember to check your spam or junk folder