‍How to Build a Site-Month Reporting Ledger for Energy Compliance in Clappia

Compliance reporting for periodic utility or energy readings has a surprisingly simple failure mode. The readings themselves are captured correctly. The photos are there. The meter values are accurate. But when the monthly compliance report is due, someone discovers that three sites submitted twice and two sites did not submit at all. The data volume looks right in aggregate, but the per-site coverage is wrong. Correcting it requires manually cross-referencing submission records against a site list, which takes time nobody has at the end of a reporting period.

The root cause is almost never people making mistakes. It is the absence of a submission registry. When every reading goes into a single app with no secondary record of which site-month combinations have been covered, there is nothing to check against and no way to catch gaps or duplicates until someone looks for them.

A Site-Month Log solves this in the simplest possible way: three fields, no workflows of its own, written to automatically by the reading app every time a submission is saved. It does two things simultaneously. It gives the duplicate check in the reading form something to query against. And it gives compliance managers a filterable ledger showing exactly which sites have submitted for which reporting period, without anyone having to generate a custom report or export data.

This guide walks through how to build that ledger in Clappia, how to wire it to your reading app via a workflow, how to use it as the basis of a duplicate prevention check, and how to turn it into a practical compliance monitoring view.

What the Site-Month Log Is and Is Not

Before getting into the build, it helps to be clear about the role this app plays in your system, because it is intentionally narrow.

What it is: A lightweight, automatically maintained registry of site-month pairs. Each record says, in effect, 'Site X submitted a reading for Month Y'. It is queryable, filterable, and used as a reference by the reading form to check whether a submission already exists before allowing a new one.

What it is not: A replacement for the reading app or a data store for meter values, photos, or any reading-specific data. None of that belongs here. The Site-Month Log contains only the minimum identifying information needed to answer one question: has this site already submitted for this period?

This narrow scope is intentional and important. A lightweight, three-field app is fast to query, easy to maintain, and impossible to confuse with the actual reading data. If you add more fields to it over time, you risk turning it into a parallel data store that drifts out of sync with the reading app. Keep it small.

The best compliance ledger is the one that answers the compliance question accurately and adds no complexity beyond that. Three fields are enough.

Step 1: Build the Site-Month Log App

Log in to your Clappia workspace. On the home screen, click '+ New App', choose a blank template, and name the app 'Site-Month Log'. This app has no workflows and requires no sections beyond the default. Add three Single Line Text blocks:

All three fields should be left as plain text with no validation rules, no required settings, and no display conditions. They will never be filled in manually. Every record in this app is created programmatically by the reading app's on-save workflow, so the fields need only be present and writable.

There is an optional fourth field worth considering: a Code Scanner block or a secondary text field for an internal reference code. This is useful if your sites carry multiple identifiers and you want to cross-reference the ledger against a different ID system. It is not required for the duplicate check or the compliance reporting view, but it costs nothing to add if your site master data uses more than one identifier.

Step 2: Wire the Reading App Workflow to Write to the Ledger

The Site-Month Log only works if it is kept current. That means every time a reading is submitted in the reading app, a corresponding record must be created in the log automatically. This happens through the on-save workflow in your reading app.

Open your energy or utility reading app in Clappia. Go to Design App and then Workflows. Under the New Submission Flow (which fires every time a new submission is saved), add a 'Create Submission' action. Configure it to create a new record in the Site-Month Log app with the following field mappings:

The Month Year field in your reading app is a Formula block that formats the reading date into a consistent text string. That formula should already exist in your reading app. If it does not, add a Formula block labelled 'Month Year'. In the formula editor, type @ to insert a field variable by selecting from the list of fields in your app, and Clappia wraps it in curly brackets automatically:

TEXT({Reading Date}, "MMM-YYYY")

Fields used: Reading Date.

What the formula does: Converts the date value selected by the user into a short text string.

What the user sees: A read-only field showing something like 'Jun-2025'. This exact string is what gets written to the Site-Month Log, so every record in the ledger uses the same format regardless of how different users entered the date.

Consistent formatting of the Month Year value is not cosmetic. The duplicate check queries the Site-Month Log by matching this string exactly. If one submission writes 'Jun-2025' and another writes 'June 2025' or '06-2025', they will not match and the duplicate check will fail silently. The formula ensures that every submission produces the same string for the same calendar month.

Step 3: Build the Duplicate Check in the Reading App

With the Site-Month Log being written to on every save, it can now serve as the reference for a live duplicate check inside the reading form. The check fires when a user selects a site and queries the log to see whether that site-month combination already exists.

Add the Lookup Block

Inside your reading app, add a Get Data from Other Apps block, which lets your form query another app in your Clappia workspace. Point it at the Site-Month Log app. Configure three query filters that must all match for a result to be returned:

• Site ID from the current form equals the Site field in the Site-Month Log
• Month Year from the current form equals the Month Year field in the Site-Month Log
• Region / Circle from the current form equals the Region / Circle field in the Site-Month Log

When all three conditions match, the block pulls the Site and Month Year values from the matching log record into hidden fields in the current form. When no match is found, those hidden fields remain empty.

Add the Validation Block

Add a Validation block with a condition that fires when the hidden Site field pulled from the log, the hidden Month Year field pulled from the log, and the current form's Site ID field are all non-empty at the same time. Set the error message to something clear: 'A reading for this site has already been submitted for this period. Duplicate submissions are not allowed.'

This validation fires at save time and prevents the submission from going through. The user sees the error message, understands what happened, and does not need to contact anyone to find out why their submission was rejected. The Site-Month Log entry created by the first submission is what triggered the block.

One behaviour worth noting: the Get Data from Other Apps block only evaluates after the site picker has been populated. If a user opens the form without selecting a site, the query does not run and the validation does not fire. This is correct behaviour. The check only becomes relevant once the site is selected, because only then is there a specific site-month combination to check against.

Step 4: Use the Ledger for Compliance Monitoring

Once the workflow is in place and submissions are being written to the Site-Month Log, the ledger becomes your primary tool for tracking monthly coverage. Unlike the reading app itself, which contains detailed meter data, photos, and remarks, the Site-Month Log contains only the three fields needed to answer coverage questions quickly.

Filtering by Reporting Period

In Clappia's submissions view for the Site-Month Log app, use the filter controls to show only records where Month Year equals the current reporting period, for example 'Jun-2025'. The resulting list shows every site that has submitted a reading for that month. Compare it against your site master list to identify gaps.

This filter takes about ten seconds to apply and gives an operations manager a complete picture of submission coverage for the period without opening any individual reading records or exporting any data.

Filtering by Region

Add a second filter for Region / Circle to see coverage within a specific geographic area. A regional manager can check at a glance whether all sites in their area have submitted without having to filter the full reading app by region and count records manually.

Spotting Anomalies

Because the duplicate check prevents double submissions from going through, the Site-Month Log should have exactly one record per site per reporting period when the system is working correctly. If you see two records for the same site and month, it means a submission got through before the duplicate check was in place, or the check was bypassed through an admin workflow. Those anomalies are easy to spot precisely because the ledger is small and simple. A three-field list with one row per site per month is easy to scan; a full reading app with meter values, photos, and remarks fields is not.

Example Dashboard View

‍

The 'Status' column in the example above is not a field in the Site-Month Log itself. It is an analytical interpretation: a site appears as 'Submitted' if a record exists in the log for that period, and as 'Missing' if your site master contains it but the log does not. Building that comparison requires cross-referencing the log against your site master, which you can do by exporting both to a spreadsheet or by building a more advanced lookup in Clappia using a Get Data from Other Apps block in a separate reporting app.

Keeping the Ledger Clean Over Time

Because every submission creates a record in the Site-Month Log, the app will grow by one record per site per month indefinitely. For most operations, this is not a problem: even a network of 500 sites generates only 6,000 records per year, which Clappia handles comfortably. But there are a few housekeeping habits worth establishing from the start.

• Do not delete records: Each record in the Site-Month Log is what makes the duplicate check work. Deleting records retroactively removes the guard for that site-month combination and could allow a re-submission that should be blocked.
• Do not edit records manually: The three fields are written by the workflow and should only ever contain values that match the corresponding reading submission. Manual edits break the mapping and make the duplicate check unreliable.
• Archive old periods if needed: If you want to keep the working view clean, you can filter the submission list to only show records from the last three months. Older records remain in the app and continue to block duplicate submissions for past periods, but they do not clutter the compliance view.

How the Three Apps Work Together

Zooming out from the ledger itself, it helps to see how the Site-Month Log fits into the broader system it supports. The three apps involved are:

1. Site Master: The reference app containing one record per site with identifiers, location fields, and contact details. The reading app pulls site data from here when a user selects a site. No workflows.
2. Energy Reading App: The transactional form where meter readings are captured. It queries the Site-Month Log to check for duplicates before allowing a submission, and writes to the Site-Month Log on every successful save.
3. Site-Month Log: The ledger. It receives writes from the reading app and answers queries from the reading app's duplicate check. No workflows of its own.

The reading app is the only one with workflows. The other two are pure data stores. This separation of concerns keeps the system maintainable: if you need to change the duplicate check logic, you only touch the reading app. If you need to update site information, you only touch the Site Master. The Site-Month Log never needs to be configured again after the initial setup.

Access and Permissions

The Site-Month Log should be treated as a system app rather than a user-facing app. Most team members do not need direct access to it; they interact with it only through the reading form, which queries and writes to it in the background.

• Field teams: No direct access needed. The duplicate check operates invisibly when they use the reading form.
• Compliance managers and regional supervisors: Should have view access to the Site-Month Log so they can filter by Month Year and Region to check coverage without needing to open the full reading app.
• App administrators: Full access to configure the app and review any anomalies in the ledger data.

The Site-Month Log is not a form that field teams ever open on their phones. It is a backend registry. That said, if a compliance manager needs to check coverage from a mobile device, the app is fully accessible through the Clappia mobile app and filters work the same way as on desktop. There is no offline use case for the ledger itself since it is a reporting tool rather than a data capture tool.

Conclusion

Three fields. No workflows. Written automatically. That is the entire design of the Site-Month Log, and it is enough to solve two problems that manual reporting processes handle badly: preventing duplicate submissions and confirming per-site coverage within a reporting period.

The value comes not from the complexity of the ledger but from its consistency. Because every submission writes to it through the same workflow with the same field mappings and the same date format, the records are uniform and reliable. A compliance manager looking at the filtered log for any given month can trust that what they see is accurate, complete, and current. That trust is hard to build with manual processes and surprisingly easy to build with a three-field app wired to an on-save workflow.

If you are already running an energy or utility reading app in Clappia and do not have a Site-Month Log in place, adding one is less than an hour of configuration. Build the app, add the three fields, add the workflow action in your reading app, and the ledger starts populating with the next submission. Everything before that date is a gap in the history, but everything from that point forward is covered.