A note from Kyros Digital
We're genuinely excited to partner with you. This proposal is our first concrete step toward taking the manual work off Beeke Investments' plate — and we don't take the trust that comes with that lightly. Let's build something durable together.
Tap anywhere to close
Engagement Objectives
Companion to the Custom Automation & Integration Services proposal. This document supplies what the proposal deliberately leaves open — what the sprints are for.
$50,000
Total Engagement
400 hrs
at $125 / hour
2-wk
Sprints
Delivered at 20 hrs/wk (~5 months) or 10 hrs/wk (~10 months)
Beeke's three priorities — bookkeeping, utility process, and real-time data from flips — become Objectives 1 through 3. Objective 4 is the foundation all three rest on. Objective 5 names the expansion track without pulling it into this budget.
Each objective is written to match the proposal's sprint framework: discovery that establishes facts and a baseline, a proof of concept that ships inside two sprints, and a recommendation on what to configure, what to buy, and what to build.
Get every transaction coded to the right property, automatically.
Beeke's number one, in five parts: coding bank transactions by property, getting data out to Sheets and the app, checks, taxes, and the automations connecting them.
The intuitive approach — point software at the QuickBooks bank feed and code each transaction to a property — is not available. QuickBooks does not expose "For Review" bank feed transactions through its API. Transactions imported from the bank but not yet categorized can be neither read nor written programmatically.
Knowing this in Sprint 1 rather than Sprint 5 is worth real money. Three paths remain, and they combine:
Up to 2,000 rules per company file, 5 conditions each, auto-post available. Where a property is inferable from bank text, rules handle it at zero build cost. But class, location and customer/project are not rule-settable — and that's where this path ends.
Carry the property dimension yourself, then match against the feed. Full control, more build, sidesteps the For Review gap entirely.
For whatever the first two can't reach. Kyros runs this pattern in production today for another multi-entity client — OCR, entity and location mapping, posting, exception queue.
The first thing we would do: sample 90 days of bank transactions per entity and measure what percentage carry enough signal in the bank text to be attributed to a property mechanically. That one number picks the architecture, and it is answerable inside Sprint 1.
Proof of concept: build the rule set for one entity's highest-volume recurring transactions, enable auto-post, and measure how much of the feed clears itself untouched.
Whatever mechanism codes a transaction, the property must land on a field that can be read back out. The options narrow fast:
Tags
Read-only through the API — retrievable, not creatable or updatable.
Custom Fields
Read-only through the API. Advanced exposes only the first three string fields.
Projects
No dedicated API entity. Behave as flagged sub-customers. Profitability not retrievable.
Class or Customer:Job
The practical property dimension. Decide in the first two weeks.
Classes require QuickBooks Online Plus or above, so confirming Beeke's plan tier is a five-minute question with architectural consequences.
There is already a canvas app displaying data from Sheets. Which Google product it is changes the recommendation completely, and the two are easy to confuse:
Gemini inside Google Sheets (GA August 2026). Turns a spreadsheet into an interactive, read-write app that reads and writes the sheet live — edits flow both directions. Inherits the sheet's sharing settings.
If it's this, that's the single best news in this engagement. Beeke already owns a live, self-updating display layer they built and like. The work becomes making the sheet continuously and correctly fed — a large chunk of scope converts from build to data quality.
The prompt-to-prototype surface at gemini.google.com. Generates interactive apps from a prompt, but output is static by default — values baked in at generation time. Live data requires custom plumbing and separate hosting.
It proved the appetite, which is genuinely useful. But it cannot be the foundation, and saying so early is better than discovering it in month three.
Discovery takes ten minutes: open it and establish which product it is, who owns it, whether edits flow back to the sheet, and what Workspace tier Beeke is licensed for.
Bank feeds carry a check number and an amount, but rarely payee or memo detail — precisely the information needed to attribute the check to a property. The likely path is OCR against bank-side check images or the issuing register, feeding the same property-mapping layer as everything else.
Discovery: how are checks written today, how many per month, and is there a digital source — bank check images, a check-printing system — or only paper?
Pulling QuickBooks and Sheets data into tax preparation documents. Annual, deadline-driven, and the piece most likely to pay for itself in a single cycle.
Discovery: who prepares the return, what format do they want, and what does assembling the package cost today in hours and people?
Percentage of bank transactions coded to a property with no human touch
Hours per month in categorization
Hours to assemble the tax package
Design document before build. This is a process problem before it is a software problem — and automating a bad process only makes it fast and permanent.
At Beeke's transaction pace, utility accounts are opened, transferred and closed constantly as properties move in and out. The failure modes are expensive and quiet — paying for a property already sold, a property without power during a showing, deposits never recovered, a bill landing in the wrong entity's books.
Walk the process end to end: who contacts the utility, what triggers it, where it is recorded, how the bill reaches the right property in QuickBooks, and who catches an account that should have been closed. Rob offered an on-site walkthrough during scheduling — this is the objective to spend it on.
A process design document: current state, failure modes with rough cost attached, recommended future state, and the automatable steps identified and sized. This lands in the first two sprints and costs very little relative to what it de-risks.
Likely a trigger off the acquisition and disposition events, an owned checklist, and utility bills flowing to the correct property coding automatically — which routes straight back through Objective 1.
Utility bills paid on properties no longer owned.
Deposits recovered.
Days from close to utilities transferred.
Deal economics live in Google Sheets — purchase, rehab, carry, disposition — while the ledger lives in QuickBooks, and the two are reconciled by hand. Margin per deal only becomes trustworthy well after close.
This is the number the business runs on. Live, it means seeing a deal go sideways while there is still time to act. After close, it is a history lesson.
This is the payoff of Objective 1, not a separate build. Real-time per-deal data is a consequence of transactions carrying a property the moment they land. Objective 1 is the plumbing; Objective 3 is what comes out of the tap. Sequence and sell them together. And if the existing app turns out to be Sheets canvas, the display layer is already built — the entire remaining problem is the data behind it.
QuickBooks Projects will not serve this through the API — no dedicated project entity, projects behave as flagged sub-customers, and project profitability is not retrievable. The per-deal P&L gets computed from transaction-level data carrying the property dimension, on our side.
Which fields live only in the Sheet — ARV, underwriting assumptions, days on market, buyer? And what is the definition of margin: is carry in, is overhead allocated, is commission? Get it in writing. Two people in the same company will define it differently, and the report has to pick one.
Five closed deals and five in flight. Compute the deal P&L from QuickBooks, reconcile against the Sheet, publish the variance. That variance report is the first real deliverable, and it will be uncomfortable in a productive way.
Days from close to a final deal P&L.
Manual reconciliation entries per month.
Beeke operates through multiple LLCs. If each set of books grew its own chart of accounts and conventions, every automation above needs a translation layer maintained forever.
Cheapest and highest-leverage work in the engagement, and the least glamorous — which is why it rarely gets done. Every automation built afterward goes faster, every cross-entity number becomes trustworthy, and the next acquisition becomes an hour of setup instead of a week.
Export the chart of accounts from each QuickBooks company and diff them. Confirm one company file per entity versus Classes inside a shared file. Confirm who holds admin rights and whether one person can authorize connections for all of them.
A standard chart of accounts, Class and Location conventions for property and entity tagging, and a written new-entity onboarding checklist.
QuickBooks authorizes per company file. Each entity is a separate connection whose credentials expire on a rolling window and must be refreshed correctly, or that entity silently stops syncing — no error, just stale data. Across several entities this is ongoing operational responsibility, not one-time setup, and it is one of the better arguments for the retainer model the proposal already makes.
Percentage of accounts mapping one-to-one across entities.
Time to onboard the next entity.
Naming these unscoped shows Beeke the relationship has somewhere to go while keeping them out of the first budget.
The underwriting model. The natural extension once per-deal actuals are trustworthy — actuals are what make a proforma honest rather than aspirational.
Flagged in planning; needs its own discovery before it can be sized.
Cheap, and it means proof-of-concept work happens without touching Beeke's live books. Worth standing up in week one.
400 hours is ten two-week sprints at the accelerated pace, twenty at the steady pace. The sequence is the same either way; only the calendar stretches.
The bank-text attribution study, the chart of accounts diff, the canvas app determination, and the plan tier confirmation. Output: a coverage number, an architecture decision, and the prioritized backlog the proposal's Next Steps already call for.
Lock the property dimension and start the bank rule build on the highest-volume entity. Alongside it, the utility process design document.
Auto-post live on one entity, with a hard number for how much of the feed clears untouched. This is the deliverable that justifies the rest of the engagement.
Extend coding coverage to the remaining entities; stand up the check pipeline; publish the first deal-margin variance report.
Build against the design document from Sprint 2.
Connection monitoring so no entity goes quietly stale, exception-queue tuning, and documentation.
Sequencing principle worth stating out loud on the call: Sprint 1 produces measurements, not software. That is deliberate. Every hour spent building before the attribution number is known is an hour bet on an architecture nobody has tested.
Every claim here is sourced. Here's exactly how confident we are in each, and where the asterisks live.
Against Intuit and Google's own documentation, September 2026
Reported consistently across developer sources
Worth confirming against Intuit's API reference before it goes in front of the client.
From the September 3 discovery: transaction coding pain and per-deal margin pain.
Six questions that shape the architecture. Each is answerable in a single conversation — and each one answered early saves rework later.
How many entities, and does each have its own QuickBooks company file or do they share one separated by Class?
Which QuickBooks Online plan tier? Classes and Projects both require Plus or above.
Is the existing app Sheets canvas or Gemini Canvas, who owns it, and what Workspace tier is Beeke licensed for?
How are checks issued, and are digital check images available from the bank?
Who prepares the tax return, and in what format do they want the package?
What is the working definition of margin per deal?