A supplier submits a revised equipment table together with a statement that only a few values changed. The receiver should establish that the old and new tables identify the same rows and columns before interpreting a difference report. Comparing values in their visible positions can answer the wrong question if records moved or labels changed. This checklist defines evidence to request for a table handover; it does not compare a real supplier's files or declare equipment accepted.
Retain the original and revised delivery identities, including their versions and intended relationship. Ask whether the revision replaces the whole table, adds records or changes only a defined subset. A comparison of a full catalogue with a filtered export needs an explanation of that scope before any row can be classified as missing.
Request a stable row identity where the data design provides one. A display position is not automatically a record identifier, and a human-readable description may not be unique. If the supplier has no suitable key, document how rows are intended to correspond and leave ambiguous matches unresolved. Do not invent identifiers by copying nearby descriptions.
The pandas DataFrame.compare documentation states its requirement for identically labeled tables of the same shape. That is a prerequisite of this particular operation, not evidence that every delivered table naturally satisfies it. Retain the observed row and column labels so the reviewer can establish whether the intended comparison is applicable.
If labels differ, first determine whether the difference represents a new record, a changed field name or an unintended preparation step. Sorting or renaming a working copy may be appropriate under an agreed mapping, but preserve that mapping and the received files. Silently forcing both tables into a convenient order can hide precisely the change the recipient needed to review.

The pandas testing reference for assert_frame_equal exposes checks covering properties such as data types, ordering choices and value-comparison settings. A test result is interpretable only with its selected conditions. Record those conditions and the software version instead of reporting a bare pass or fail.
Do not disable a label or data-type check simply because the initial result is inconvenient. Ask whether the disabled property is relevant to the delivery contract. A numeric-looking identifier represented as text and the same-looking field represented numerically may have different downstream roles even when a display makes them appear similar.
Likewise, any approximate value comparison needs a separately justified rule. This checklist does not choose a tolerance or determine whether a measured equipment quantity is acceptable. The table-comparison configuration describes how two data representations are compared; operational limits belong to the appropriate specification and review process.
A difference report should identify the affected row, field and versions without requiring the reader to infer a source from alternating columns. Ask for enough surrounding context to locate each finding in the received material. A compact output may be useful for technical investigation but insufficient as the only explanation supplied to a purchasing or documentation team.
Preserve matching and nonmatching scope deliberately. A report that displays only differences should not be mistaken for a complete copy of the submitted tables. State which operation produced it and how unchanged records can be checked if needed. Do not fill omitted cells with invented values merely to make the report resemble the original spreadsheet.
For missing values, retain the stated representation and relevant comparison behavior. A blank display can represent several situations in an application. The reviewer should not describe an unchanged missing marker as a new equipment reading, or assume that every visible empty cell has the same source meaning.

When row correspondence is unresolved, return a specific question tied to the delivered file and affected labels. A supplier can then provide a mapping or corrected export. Keep the original finding and revised delivery linked, so another reviewer can see why the comparison method became applicable later.
The acceptance conclusion should separate verified structure, configured comparison results and unresolved interpretation. A comparison passing under a permissive configuration does not establish that all fields meet the intended handover requirements. A failing strict check does not prove that the equipment itself is defective. State exactly which data question was tested.
For future revisions, preserve the agreed row-key and field-label conventions with the method note. Recheck them whenever an export or software version changes. A stable filename or similar screenshot is not sufficient evidence that the next table can be compared under the earlier assumptions.
The original illustrations contain no supplier records or computed differences. More review methods are in the equipment specification records collection and article directory. Verifying table labels first makes a change summary easier to assess without replacing equipment-specific technical acceptance.