The W3C tabular data model<\/a> also illustrates why a table and its descriptive metadata serve different purposes. A CSV payload needs context about its columns and interpretation. For an engineering delivery, the manifest adds a further project-specific layer: what was requested and how the payload relates to that request.<\/p>\n Keep the original payload and the original received manifest. If the producer corrects either, store a new revision and link it to the superseded delivery. Do not silently alter a manifest to match the folder after discovering an omission.<\/p>\n A manifest can be a controlled spreadsheet, a machine-readable file or an approved record in a document system. Choose a form that the recipient can validate and preserve. Its fields matter more than its visual complexity. Avoid confidential access details and unnecessary personal information.<\/p>\n This is a project checklist, not a mandated industry file standard. Derive the actual required fields and acceptance limits from the receiving agreement, applicable obligations and measurement purpose.<\/p>\n Compare the expected inventory with the received inventory. Flag missing, unexpected and duplicate entries separately. Two files with similar names may cover different periods; two differently named files may contain identical bytes. Keep those situations distinct in the review record.<\/p>\n If a delivery is split into multiple parts, identify all parts and define when the batch is complete. A recipient should not accept part one as the whole delivery simply because it arrived without an error. Store the expected part count or another explicit completion signal in the agreed envelope.<\/p>\n Do not trust an archive’s filename as proof of its contents. Inspect its inventory in an appropriate controlled environment and compare its members with the manifest. Apply your organization’s security and handling procedures before opening unfamiliar material. This workflow does not require bypassing endpoint controls to finish an engineering review.<\/p>\n A file count is only the first layer. Compare the supplied point identifiers with the approved point list. Then check the requested time coverage for each channel, accounting for documented outages, commissioning dates and deliberate exclusions. A valid file can contain an empty selection.<\/p>\n For regular interval data, derive the expected interval count from the agreed window and time convention. For an illustrative 24-hour fixed-offset window at 15-minute intervals, the expected number is 24 multiplied by 60 divided by 15, or 96 intervals per channel. This example assumes a full fixed-offset day, uninterrupted eligibility and one row per interval. Local civil days, daylight-saving transitions and other export layouts require their own calculation.<\/p>\n If a hypothetical batch covers ten eligible channels under those assumptions, the expected total is 960 interval records. Receiving 960 rows is still insufficient by itself: one channel could be duplicated while another is missing. Check the combination of channel and interval identity, not only the grand total.<\/p>\n Classify a missing file separately from missing readings within a file. Record whether the cause is selection, collection, communication, processing or delivery. If the cause is unknown, say so and assign an investigation owner instead of substituting a convenient explanation.<\/p>\n A zero reading is not a substitute for an unavailable reading. Likewise, an interpolated or estimated value should carry the agreed quality meaning rather than being presented as an original observation. The manifest should reference the applicable quality convention and summarize unresolved coverage, while detailed row-level evidence remains in the supporting record.<\/p>\n Where a gap is accepted for a restricted purpose, document that restriction. A dataset may support a maintenance trend while remaining unsuitable for a complete energy reconciliation. Acceptance should describe the permitted use, not give the whole folder an unrestricted pass.<\/p>\n Suppose a delivery omits one feeder for part of the requested period. The producer sends an additional file later. Identify whether the new file supplements the original batch or replaces an earlier file. Include explicit scope so the receiver knows which records should be added and which should be superseded.<\/p>\n Keep the original received files unchanged. Reconcile the correction against the same approved selection, then record the new accepted delivery state. Test how the receiving system handles overlapping intervals before importing the correction into a live reporting dataset.<\/p>\n For related controls, see the duplicate meter energy record guide<\/a> and the export file integrity guide<\/a>. The former addresses record identity and duplicate handling; the latter addresses preservation and byte comparison. Neither replaces a delivery-wide completeness decision.<\/p>\n Assign a reviewer who can access both the agreed scope and the delivered evidence. Record the review date, checks performed, exceptions and decision. A signature alone is insufficient when the scope and evidence cannot be found. Link to a controlled location rather than a temporary personal download folder.<\/p>\n Set ownership for unresolved items and a follow-up date. Avoid closing an exception merely because a supplier acknowledged an email. Close it when the missing evidence is delivered and checked, or when an authorized person accepts a documented limitation for a defined purpose.<\/p>\n Preserve the manifest alongside the relevant contract revision and point mapping. A later reviewer needs to know what the recipient expected at the time, even if the current system now has more meters or a different export structure. This is particularly useful when investigating a report that was produced before a configuration change.<\/p>\n![\"BY194](\"https:\/\/cnbygele.com\/wp-content\/uploads\/2026\/11\/meter-export-manifest-completeness-inspection-20261108.png\")
Use a manifest that supports a real decision<\/h2>\n
\n\n
\n \nManifest section<\/th>\n Minimum useful record<\/th>\n Recipient check<\/th>\n<\/tr>\n<\/thead>\n \n Delivery identity<\/td>\n Batch identifier, producer and revision<\/td>\n Matches the requested delivery and supersession chain<\/td>\n<\/tr>\n \n Selection scope<\/td>\n Approved point-list revision and filters<\/td>\n Every required asset and channel is represented<\/td>\n<\/tr>\n \n File inventory<\/td>\n Relative name, size and agreed digest<\/td>\n Files exist and match the recorded evidence<\/td>\n<\/tr>\n \n Time coverage<\/td>\n Requested and actual bounds with convention<\/td>\n Gaps and overlaps are identified explicitly<\/td>\n<\/tr>\n \n Interpretation<\/td>\n Contract revision, unit and quality-code context<\/td>\n Receiver can interpret the supplied values<\/td>\n<\/tr>\n \n Exceptions<\/td>\n Missing items, reason, owner and disposition<\/td>\n No unresolved item is silently accepted<\/td>\n<\/tr>\n \n Acceptance<\/td>\n Reviewer, decision and evidence reference<\/td>\n Decision can be reproduced later<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n Reconcile files without mistaking names for identity<\/h2>\n
Reconcile coverage at the measurement level<\/h2>\n
Handle gaps as evidence, not cosmetic defects<\/h2>\n
A correction workflow that avoids double counting<\/h2>\n
![\"BY194](\"https:\/\/cnbygele.com\/wp-content\/uploads\/2026\/11\/meter-export-manifest-completeness-records-20261108.png\")
Make the record usable during handover<\/h2>\n
Connect the delivery back to the installation<\/h2>\n