Property portfolio reporting: show incomplete data before the totals

Build an expected-properties table for the reporting period. Include a stable property identifier, reporting owner, source system, expected submission, and whether that property is included for the full period or under a documented exception.

Do not derive that list only from the files that arrive. If the collection process receives nine files, it cannot tell you whether ten were expected. The expected set needs its own source and an owner who can explain additions, disposals, and reporting exclusions.

Property names should be display labels. A building may have an old name in one export and a new name in another. Join records with a stable identifier and retain a reviewed alias mapping where needed. A model can suggest a possible match, but an uncertain match should remain unresolved until someone approves it.

A file generated in August may describe July, contain a June adjustment, or include year-to-date figures. File timestamps alone cannot decide which reporting bucket it belongs in.

I would require explicit fields for the period covered, the source's extraction time, and the report's cutoff. Preserve these separately. A late adjustment should create a documented revision rather than silently changing a report that has already been distributed.

For each metric, record its definition and unit. A percentage needs a denominator. An amount needs a currency. A count needs an inclusion rule. If two property systems use different definitions of an occupied unit or an open work order, an aggregation can be mathematically tidy and operationally misleading.

Start with fewer agreed metrics. Expanding a report before agreeing what its fields mean creates a longer reconciliation queue without adding confidence.

I would calculate totals and ratios with ordinary code or database queries. The language model can help explain a verified result, but it should not be the calculator of record.

A database can enforce basic requirements such as unique record keys and references to valid properties. PostgreSQL's documentation describes unique, foreign-key, and check constraints, which are useful building blocks for this kind of validation. They still need to reflect the business definitions agreed by the reporting owner. PostgreSQL constraints

Useful checks include duplicate property-period submissions, missing units, conflicting currencies, and totals that disagree with the source export. A failed check should retain the original values and a reason code. Replacing an unexpected value with zero makes the report easier to finish and harder to trust.

Some exceptions are legitimate. A property may have no activity for a metric. Record an explicit zero when the owner confirms that condition. Keep it distinct from an absent value or a source that failed to load.

Imagine a hypothetical report covering ten properties, with nine accepted submissions and one outstanding. The report should say that before showing a portfolio total. Label the total as partial and identify the excluded property through an appropriate internal reference.

The interface should offer a completeness summary, a list of unresolved exceptions, and the accepted data cutoff. A recipient should not need to inspect an engineering log to learn that a source is missing.

For distribution, define which gaps block release. An internal working report may be useful while incomplete. An externally distributed report may require every required submission or a named owner's explicit exception approval. The workflow should support both states without presenting them as the same finished product.

Once the data is accepted, pass the model a compact facts table and the approved metric definitions. Ask for a draft narrative that cites the fact identifier behind each material statement.

Keep explanations separate from observations. If open work orders increased, the dataset may show the increase without explaining why. The draft should not invent staffing problems, tenant behavior, or vendor delays to make the paragraph feel complete. It can identify a question for the property manager instead.

I would also prohibit forecasts unless a separately approved forecast is part of the input. A month-over-month movement does not automatically establish a trend, and a generated sentence should not imply that the next period is predictable.

The reviewer should see the narrative beside the relevant figures and exceptions. That layout reduces the work of checking a sentence against a spreadsheet buried in another application.

Give every distributed report a version identifier and a manifest of its accepted inputs. If a source changes, create a new candidate version, calculate the difference, and show which figures and paragraphs changed.

An approval should bind to that particular version. If the model regenerates the narrative or a late file changes the totals, the previous approval should not silently cover the new content.

Distribution should retain a receipt showing the report version, approved recipient group, and delivery outcome. A successful upload does not prove that every recipient received the intended file. If the workflow fails after upload but before notification, the operator needs to resume the missing step without generating a confusing second report.

For a pilot, use sanitized or synthetic exports that represent the reporting formats you actually expect. Include a missing property, a renamed property, a duplicate file, a wrong month, a late adjustment, and an intentionally blank metric.

Ask the operations team to state the expected result for each case before running it. A workflow that “handles” a missing file by excluding it may be technically successful and contrary to the reporting policy.

Test the narrative separately. Insert a verified increase without a reason and confirm that the draft does not supply one. Give the model contradictory source facts and verify that it flags the conflict instead of choosing the more convenient figure.

Measure reviewer time, unresolved exceptions at release, revision frequency, and the share of generated statements that required correction. Those measures describe the reporting workflow more usefully than the number of paragraphs the system produces.

I would choose one recurring report with a named owner, stable recipients, and accessible source exports. The first implementation should establish collection, validation, exception handling, narrative review, and versioned distribution for that report.

If the source systems cannot supply reliable identifiers or period fields, resolving those inputs belongs in the scope. A prettier dashboard cannot compensate for ambiguous records. It can conceal the ambiguity well enough that it spreads.

Bring a redacted example of the report, its source exports, and the checklist the reviewer uses before sending it. Those artifacts make it possible to scope the work around a real decision and a real handoff.