A site supervisor photographs an unexpected obstruction. The crew agrees on a reroute, materials are ordered and the work proceeds. Weeks later, the office has an invoice, a text conversation and a revised drawing, but no clear connection between them. The change happened physically before it became a reliable commercial record.
For an Edmonton construction team considering custom software, this is a better starting point than another dashboard of project totals. The useful project connects a change's evidence, pricing, authorization, completion and billing without pretending those are all the same event.
One change can have several valid states
In an illustrative electrical project, a proposed cable reroute may be documented but not priced. Later it can be priced but awaiting a commercial decision. Part of the work may be completed while an associated material delivery is still outstanding.
A single status called approved cannot explain all of that. It might refer to a supervisor acknowledging the site condition, a customer accepting a price, an engineer reviewing a design or somebody authorizing an accounting entry.
Model these decisions separately and identify who can make each one. The interface can still be simple: a timeline of the change, current responsibilities and the next unresolved action. The underlying record needs enough structure to explain why an invoice line exists and which evidence supports it.
Municipal progress and commercial progress are different
The City of Edmonton's Self-Serve help centre describes online permit applications, project tracking and inspection requests. That municipal workflow is important context, but it does not decide whether a customer accepted a commercial variation or whether a supplier invoice was reconciled.
Your project software can record the relevant permit reference and an observed status with its source and date. It should not imply that a field supervisor's internal approval changes the City's record. Nor does an available public portal prove that a supported automation API exists.
This distinction is useful in everyday design. A project manager can see a permit-related dependency beside a commercial decision while understanding that different people and systems control them. Connecting context does not require collapsing authority.
Preserve the invoice's own history
Alberta's prompt-payment guidance sets out requirements for proper invoices and explains that revisions require agreement, an unchanged invoice date and continued compliance with the requirements. It also distinguishes Alberta government project contracts under the Public Works Act from the timelines under the Prompt Payment and Construction Lien Act.
That makes a software shortcut dangerous: replacing the original invoice date with the date an internal manager finally approved a change. Store receipt, invoice, review and revision events separately. Have the people responsible for the contract confirm the applicable rules before turning them into reminders or workflow conditions.
An application should preserve the record needed to understand a payment decision. It should not silently restart a timeline because a user clicked a button or an integration retried a transaction. Software configuration alone is not a legal assessment of a particular invoice or contract.
Follow the reroute from field evidence to billing
The supervisor creates a change record with the project, location and a concise description. Photos and drawing references attach to that record. An estimator adds the pricing revision, and the responsible person records the commercial decision without overwriting the original request.
When work is performed, the field entry references the same change identity. Quantities and supporting notes can be checked against the agreed scope. The office sees which parts are completed and which remain unresolved.
The accounting handoff then links the relevant invoice lines to that change and preserves the accounting system's identifiers. If a quantity is corrected, the history explains the correction. If a transfer fails, a retry does not create a second bill because the application remembers the original operation and resulting accounting record.
This is a proposed workflow, not a promise that every construction or accounting product supports it unchanged. The discovery task is to test the actual interfaces and identify where a small extension would help.
Buy a product, configure a connector or build the gap?
Begin with the construction-management and accounting tools already in use. Many teams need better configuration or a supported integration before they need a new application. Check which system owns customers, cost codes, suppliers, change records and final accounting entries.
Use a real but sanitized example to test partial completion, a revised amount and a rejected transfer. A product demonstration that only creates a clean new invoice does not show how the workflow behaves when the office corrects yesterday's entry.
Custom development is most compelling when the remaining gap is specific: capturing site evidence with the right project identity, reconciling several subcontractor formats or showing unresolved commercial decisions across existing systems. Our CRM and ERP integration guide helps frame those boundaries and operational responsibilities.
Estimate the hard handoffs before the attractive screens
Cost drivers include the number of accounting entities, inconsistent cost codes, historical records, attachment volume and how reliably field users can identify the right project. Offline capture introduces additional questions about synchronization, duplicate submissions and conflicting edits.
The first pilot should follow one kind of change through its complete lifecycle. Include a correction and a failed transfer. Invite the supervisor, estimator and finance user to review the same record, because each sees a different part of the problem.
Agree on a measurable operational goal such as finding the supporting record for a billed change without searching several conversations. Establish the baseline with your own team; do not borrow a vendor's claimed time savings. Our software discovery guide explains the artifacts that make a build estimate more useful.
TuniCyberLabs can help Edmonton teams design and connect these application workflows remotely. Explore custom software development or describe your field-to-invoice problem. Share the tools involved and a non-sensitive example of the change that currently gets lost between site and office.