How Big Robot redesigns work before building software

The engagement began with the company's executives. They wanted to reduce the manual work involved in processing owner payments and the delays that work created. They also wanted each person to know when the next action was theirs. Accounting still needed to control the money.

The original workflow map counted 31 manual steps, 6 manual emails, and 10 manual data-entry actions. It also exposed slow handoffs, missing notifications, and too much information living in the heads of a few experienced people. Automating the existing process would have made those problems move faster.

When an owner paid the general contractor, Accounting first had to determine what the money was for. The bank record did not always include a project or invoice number. One payment could cover several owner invoices or projects. Checks and EFT deposits entered the company through different paths.

Accounting recorded the payment in Sage Intacct and Procore, then added a spreadsheet entry that acted as both an audit log and a link between those records. Every entry created another chance for error.

After Accounts Receivable reconciled the payment, AR emailed Accounts Payable. AP created a report for the Project Manager, who reviewed the related subcontractor requisitions and recommended payment, a hold, or a partial payment. The Project Manager sent the completed report back to AP. Accounts Payable checked compliance and retained final payment authority.

Finance and Accounts Receivable walked us through how payments arrived and were recorded. Later demos exposed payments without useful references, payments spread across projects, batched checks, partial allocations, and an unresolved Sage Intacct write path.

We interviewed the Project Managers about the monthly subcontractor payment cycle. We turned those conversations into a structured discovery document that captured workflow differences, disagreements, and questions for Accounting.

Project type, owner requirements, and delivery method changed the work. The PMs received too many routine Procore notifications while missing payment information that required action. Most monthly reviews were straightforward. PMs needed current-cycle information, clear hold reasons, and a notification when they had a decision to make.

What looked like one payment workflow was two connected processes.

Reconciliation accounted for the money received from the owner. Pay App Review determined which related subcontractor obligations were ready to move forward. Different people did the work, used different records, and held different authority.

The interviews also clarified authority. A Project Manager could recommend pay, hold, or partial payment. Accounts Payable and Accounting still controlled the money.

Compliance introduced another handoff. A PM should not have to approve the same payment again because a subcontractor later resolved an insurance, bond, or lien-waiver problem. Once the PM made a recommendation, Accounting owned the compliance exception. When the status changed, the system needed to notify AP.

The discovery document became the working record for the next interviews and the first prototype. The prototype let the team test our inferences against real cases. It also established where the system should stop. The system could support the review, but it would not send payments. Accounting would continue to control the money.

Procore and Sage Intacct each held part of the truth. The project in Procore had to be connected to the right customer, invoices, and payments in Intacct. Neither system cleanly represented every compliance and lien-waiver requirement.

Big Robot created one shared definition of those records and their relationships. Projects connected to owner invoices and payments, which connected to subcontractor requisitions, subcontractor payments, and compliance. The model also resolved the different identifiers each system used for the same thing.

An ontology is a shared model of a business's records and how they relate.

Procore and Intacct remained the systems of record. The ontology made their records usable together. Reconciliation could connect money received with the invoices it satisfied. Pay App Review could assemble the evidence for each affected project while keeping PM recommendations and AP responsibility separate.

In the redesigned reconciliation process, an EFT deposit or photographed check starts the work. Accounts Receivable confirms the details and selects the owner invoices. The system links the payment activity in Intacct and Procore, preserves the evidence, and keeps conflicts visible. Reconciliation documents the owner payment. It does not authorize a subcontractor payment.

Completing reconciliation starts a Pay App Review for each affected project. The system assembles the relevant requisitions, payment information, and compliance status, then notifies the appropriate Project Manager. The Project Manager recommends pay, hold, or partial payment. Accounts Payable retains final authority, and actual disbursement remains outside Pay App Review.

"Move fast and break things" is terrible advice for an accounting department.

A conventional rollout would have finished the product, trained the team, and picked a cutover date. Every unresolved design choice would then become an AP problem on the same day.

We limited the first rollout instead. Early versions of Pay App Review ran beside the established AP process. Two senior Project Managers started using the new system while the rest of the project team and AP continued working as before.

Pay App Review used the shared model and stored review activity in Big Robot. It did not change the underlying Procore or Intacct records. We could learn from real payment work without forcing a company-wide rollout or disrupting the existing operation.

Incoming bank data was checked for duplicates and invalid totals. Failed writes and conflicting evidence stayed visible for a person to resolve.

The new system could be incomplete without being dangerous. Accounting kept control of every payment while the first users helped us correct the product.

The redesigned process eliminated all 10 manual data-entry actions while preserving the decisions that belonged to people. Average time from owner payment to subcontractor payment fell from 41 days to 24 days. AP items still outstanding more than 60 days after owner payment fell from 22% to 2%.

Big Robot MCP queries the same model. An authorized AI tool can ask for approved accounting information without guessing how records in Procore relate to records in Intacct. That only works because those relationships were resolved first.

In one investigation, an invoice appeared partially paid. Big Robot connected the invoice state, payment records, retainage, and line-item detail. The answer came down to nine cents. Ten cents of additional completed work minus one cent of retainage left the invoice open.

The ontology made that explanation possible without pretending either source system contained the whole answer.

A Project Executive could also ask Big Robot MCP to summarize contingencies across every open project. Answering that question requires the same project identities and source relationships used by the accounting workflows. The company can use the information for a new purpose without rebuilding those connections.

Reconciliation and Pay App Review gave Accounts Payable better information at the project level. AP still lacked one cross-project view of every payment obligation.

Approved items could remain unpaid. Paid items could look unpaid when source records conflicted. Some obligations may never enter Pay App Review. Accounting had to scan a project-by-project digest and work out what changed.

Big Robot proposed an AP Tracker that would give AP a read-only cross-project view and notify the team when an obligation became payable. It would also separate work owned by Accounting from issues that required a Project Manager, compliance, a vendor, or data support.

Solving one constraint gave the business enough visibility to find the next one worth fixing. That is what we mean by upgrading your problems.