The Logic Underneath
VERA is not a time-tracking tool with a chat interface. It is a set of enforced business rules — applied automatically, on every action, for every person on your team. This document explains what those rules are and how they behave.
Who Sees What
VERA enforces visibility rules at the permission level. There is no setting to toggle, no screen to ignore, and no workaround. Each role sees exactly what is appropriate to their responsibility — nothing more.
| Owner | Manager | Team Member | |
|---|---|---|---|
| Dollar amounts (costs, contract values, margins) | Yes | No | No |
| Percentages (budget used, margin %, utilization %) | Yes | Assigned projects only | No |
| Other people's time entries | Yes | Assigned projects only | No |
| Own time entries | Yes | Yes | Yes |
| Project deadlines | Yes | Yes | No |
| Rate information | Yes | No | No |
Managers can do their job — set up new projects and clients, distribute hours, approve time off, monitor burn rates — without ever seeing what anyone is paid or what the business earns and spends. A manager setting up a new project can enter what the client will be charged; once the project exists, that figure, like every other dollar amount, is shown only to owners. Team members log time and see their own history. Owners see everything. The separation is enforced by the system on every request, not by trust.
There is also an operator level for the people who run the business but don't deliver client work themselves. They see everything an owner sees, but they are deliberately left out of the team's capacity and utilization figures — an operator who was never expected to bill hours shouldn't drag down the numbers for the people who do. A team of eleven that includes one operator is measured as the ten who deliver.
Because the two levels see exactly the same things, an owner can move their own account to the operator level and back whenever they like, without anyone else's help. That is the only role change anyone can make to their own account; every other one would risk locking somebody out of their own business, so it has to be made by someone else.
How VERA Values Your Work
Revenue is not recognized uniformly — it depends on how the work is contracted. VERA knows the contract type for every project and applies the correct recognition model automatically.
Pro Bono projects carry zero revenue. The cost is still tracked in full, so you always know what you are giving away.
Time and Materials projects recognize revenue in real time: every hour logged is immediately worth the agreed billing rate. If a team member logs four hours, the project's recognized revenue increases the moment that entry is saved. Work should stop when the hours budget is exhausted.
Fixed Price projects use percentage-of-completion accrual. Revenue is recognized proportionally as hours are consumed against the total budget. A project at forty-five of one hundred hours has earned forty-five percent of the contract value — not zero, and not one hundred percent. VERA calculates this continuously.
Retainer projects recognize revenue per billing period, not for the engagement as a whole: each period carries its own hours budget and fee, and that period's revenue is (hours logged that period ÷ that period's hours budget) × that period's fee, on the same percentage-of-completion logic Fixed Price uses. When a vendor does some of a period's work under a fixed payment agreement, the vendor's hours count as hours logged in that period, building up evenly across the period's own dates, and rolling the retainer forward to the next period carries the agreement with it. The monthly profit-and-loss report and the month-end billing view count those hours the same way, so a month where only the vendor worked shows the revenue it earned, not nothing. A retainer never has a deadline — it resets every period instead, and VERA warns you ahead of time, both by message and on the project's own page, when the current period is about to run out with no successor set up. Whether a retainer is on course is judged on the period you are in, so a month that overran can't be hidden by an earlier month that came in under. Once you roll a retainer forward, its burn-up chart runs on through the period that is coming, so you can see the pace the next period's budget asks for.
Agile projects are supported for existing engagements — reporting, status checks, and dashboards all work as described below. New Agile engagements are not currently available; a Retainer, T&M, or Fixed Price project covers the same shape of work during this period.
Sizing a Fixed Price project correctly. When you create or edit a Fixed Price project, VERA shows you the implied scope — how many hours the contract can sustain at the billing rate you have entered. Enter a contract value and a billing rate, and VERA immediately tells you how many hours that implies; one click fills the hours budget field so you do not have to do the arithmetic by hand. It also works in reverse: enter a contract value and an hours budget and VERA shows you the implied billing rate. If that rate is at or below what your team costs to deliver — based on a rolling average of your people's cost rates over the past ninety days — VERA flags it in red. A deliberate low-margin or loss-leader project is allowed; the warning is advisory, not a gate. Its purpose is to make a pricing mistake impossible to miss before it is committed. On a fixed-price contract VERA also offers the fix: one click sets the hours budget to what the contract can pay for while still meeting your efficiency target (five dollars billed for every dollar of people cost, unless you or the project set another). On a project already under way, if more hours have been recorded than that figure, VERA says so plainly, because the target can no longer be reached, and the corrected budget then shows the project's real position instead of hiding it.
Envelope budget on Fixed Price projects. A contract value tells you what the client is paying. What it does not tell you — without more arithmetic — is how much of that you can spend on the work itself. VERA surfaces two numbers that form the ratio explicitly: the project budget (the client contract) and the people budget (the project budget divided by your efficiency target, five dollars billed for every dollar of people cost unless you set your own). For a $100,000 project at 5:1, the project budget is $100,000 and the people budget is $20,000 — meaning for every five dollars billed, one dollar is the ceiling for direct production labor. You set the target once for the whole company, and any single project can set its own instead: a strategic account you are happy to run at 4:1 gets a people budget of $25,000 on the same contract, while every other project stays at the company figure. The same target decides how VERA colors a project's efficiency ratio, from red below break-even up to the strongest green at or above target: each project is colored against its own target, and totals that add up several projects, such as a month's profit and loss or one project manager's whole portfolio, against the company's. As you assign people to the project through the allocation system, VERA sums what those hours will cost at each person's cost rate and shows how much of the people budget remains. Fixed fees — vendor and contractor payment agreements — are different: they are not people cost, so they come off the project budget first, and the people budget is what is left divided by the target. A $100,000 project with a $10,000 fixed-fee vendor at 5:1 has a people budget of $18,000, not $20,000. The fees appear as their own figure beside the budgets, and the bar shows only people cost against that smaller budget. If the fees use up the whole contract, the panel says there is no people budget left. This keeps the panel consistent with the efficiency ratio: a project's ratio is at or above target exactly when its people cost is within its people budget. The moment you over-commit the team, the status chip turns red and remaining goes negative. There are no per-person figures: the panel shows only the aggregate. The numbers update every time you load the page.
Telling VERA when hours land. An allocation can carry an optional window — a start and an end between which the work is expected to happen. Without one, VERA assumes the hours are spread across the remaining life of the project, which is the safe default when nobody has said otherwise. With one, capacity respects it: the hours land inside those weeks and stop counting against the weeks outside them, so a person booked heavily for one month no longer reads as mildly busy for six. Company holidays are excluded, and a window that has already passed falls back to the default rather than piling overdue hours onto today. A window is a bound, not a schedule — it says these hours land somewhere in this range, and it never assigns work to a particular day or tells anyone when to do it.
How efficiently your people earn: LER. VERA measures labor efficiency the way Greg Crabtree's Simple Numbers does: gross margin divided by direct labor. A fixed payment agreement with a vendor or contractor is a cost of delivering the work, so it comes off the revenue first and is never counted as labor. A $10,000 project with a $3,000 fixed fee and $2,000 of staff cost earns $7,000 of gross margin on $2,000 of labor, an LER of 3.5 to one. If nothing is left as labor, VERA shows a dash rather than a ratio.
This week is measured against what is left of it. Capacity for the week you are in counts only the working days still ahead, today included, because the hours someone is committed to are also counted from today. On a Friday, a person with 7.5 hours still committed this week and one 8-hour day left reads as 94% booked, not 19% of a 40-hour week that is mostly over. Past and future weeks are measured against the whole week.
Measuring progress against a real plan, not an assumption. When a manager goes a step further and sketches out which weeks an allocation's hours are actually expected to land in, VERA can measure the project's progress against that plan instead of assuming an even pace across the whole engagement. Without such a plan, VERA compares logged hours to a straight, even line from the project's start to its deadline — a fair default when nobody has said otherwise. Once a manager plans specific weeks, VERA compares logged hours to that plan instead, because a plan someone actually drew is a more honest yardstick than an assumption of steady effort. The comparison only starts counting from the moment the plan was made, never from the start of the project — so sketching out a plan partway through an engagement never makes the project look instantly behind on work that was already done before the plan existed; the project simply reads as on track at that moment and is judged against the plan from there forward. This is a management view: whether a project is tracking to its plan is visible to managers and owners on the project's own page, and never reaches the people doing the work — nobody is told in their own daily updates that they are behind a plan they did not write and cannot see.
When a project starts and ends. Every project has a start date and, for client work, a deadline. The start date is the day the project is created unless someone names another, and an owner or the project's manager can change it later, though never past the deadline and never later than the first hours already recorded on the project, since those hours show the work had already begun. Everything VERA says about the schedule, such as how much of the time has passed and whether the hours are on course, is measured from the start date, so changing it changes those readings for the whole life of the project. An allocation's window always sits inside the project's dates, so a project's dates can't be pulled in past a window someone has already planned, or past a month a fixed-price client is due to be billed, until that plan is changed first. Hours can't be recorded on a client project before its start date; if the work really began earlier, the start date moves back first, so the schedule and the recorded hours always tell the same story. Hours recorded after the deadline are always accepted, because projects overrun, and refusing real work would only push it onto a false date. Every change to a deadline is kept, so a project that slipped never looks as if it was always due on its new date: the project's page shows when it was originally due and each move since. Owners see how well each project manager holds deadlines. Every move later counts against them, whatever the reason, and so does running past the deadline on an active project. It is measured against the original schedule, from the start date to the first deadline.
Seeing each person, not just the total. A project's overall trajectory can look healthy while individual people on it are well ahead or well behind, because the totals cancel out — one person running two weeks ahead and another running two weeks behind average out to a project that reads as perfectly on schedule. VERA gives managers a second view on the same project, alongside the overall trajectory: each person's planned hours against what they have actually recorded, week by week, so a manager can see who needs a conversation while there is still time to act. A week where the hours recorded miss what was planned for it is marked, and a running total keeps score across the whole engagement — how many hours ahead or behind, and by what percentage — so a manager can tell at a glance whether a gap is a rounding error or a real problem. Recording well over the plan is marked just as clearly as recording under it: both mean the plan and the reality have come apart, and neither is good news on its own. The week currently in progress is never marked and never counted, because it has not finished yet and judging it would mean inventing an expectation for a particular day, which VERA does not do. Like the plan itself, none of this is ever shown to the person whose hours it is describing.
How VERA Calculates Cost
Cost follows the person, not the project. VERA applies the rate that was in effect on the date the work was performed — not the rate today.
VERA recognizes a meaningful distinction between two kinds of outside labor. Contractors sell their time the same way employees do: they log into VERA, log their own hours, and their cost is hours × their cost rate. Vendors sell deliverables: they do not use VERA at all — the project manager logs time on their behalf, and their cost is governed by a fixed payment agreement, not their hourly rate. This distinction is structural, not cosmetic. Anyone who sells you hours gets the hours treatment; anyone who sells you a finished thing gets the fixed-fee treatment.
A full-time employee costs the business more than the number on their paycheck — payroll taxes, benefits, retirement matching. VERA lets you set a single multiplier that captures that fully-loaded cost, and shows it on your compensation pages, where you can see what each person really costs to employ.
It stops there, deliberately. Project costs are never multiplied by it. An hour of someone's time costs a project that person's rate for that hour — nothing added, nothing assumed. That keeps a project's economics simple enough to check by hand: if you know the rate and the hours, you know the cost. The company-wide view of payroll burden and the project-by-project view of what work costs are two different questions, and mixing them made the second one hard to reason about.
| Situation | Cost calculation |
|---|---|
| Full-time employee logs time | Hours × the cost rate in effect on the date of the entry |
| Contractor logs time | Hours × the cost rate in effect on the date of the entry |
| Contractor with a fixed payment agreement on a fixed-price project or retainer period | Pro-rata portion of the agreed amount, exactly as for a vendor; the hours they record there are kept for reference only |
| Vendor with a fixed payment agreement on the project | Pro-rata portion of the agreed amount — accrues linearly across the agreement's own dates, by default the project's start to its deadline (on a retainer period, across that period's own dates) |
| Vendor without a fixed payment agreement | Hours × the cost rate in effect on the date of the entry |
Changing the employer cost multiplier therefore moves what your compensation pages report about employing people, and moves nothing at all about any project, report, or forecast. A full-time employee, a contractor and a vendor without a fixed agreement all cost a project the same way: hours × the rate in force on the day.
Fixed payment agreements were first reserved for vendors, and a contractor could not have one. The reasoning was operational: contractors are inside the system, accumulating hours toward an allocation, and a fixed-fee shortcut would have silently made those hours invisible to the cost engine. A contractor who needed a fixed-fee deliverable had to be set up as a separate vendor record for that engagement.
That changed when we looked at how a fixed price earns money. Picture an owner who sells $25,000 of work and subcontracts it to a developer for $5,000. What they can justifiably keep is the margin as the work is delivered, so the $5,000 cost and the $25,000 of revenue have to build up on the same clock. A fixed payment agreement does exactly that: its hours and its cost build up evenly across its dates, and on a fixed-price project or a retainer period those hours count toward completion, so revenue builds up alongside. A contractor can now hold one too, on a fixed-price project or a retainer period. They record their time exactly as before, against an allocation VERA creates for them, and those hours are kept so you can compare them with the agreed hours afterwards and price the next job better. They just don't move the project's figures: the agreement does. The agreement and that allocation are one arrangement: cancel either and both end, change the agreed hours and the allocation follows. Say the agreement is $1,000 for 10 hours over a month, on that $25,000 job budgeted at 50 hours. Half way through the month, 5 of the agreed hours count, $500 of cost has built up, and the project has earned $2,500 (5 of its 50 hours), whether the contractor has recorded 1 hour or 9. On an hourly project this doesn't apply, because there each recorded hour is what the client is billed.
This same distinction — logging in versus not — is also what decides which permissions outside labor can hold. Contractors log into VERA the same way employees do, so a contractor can be given any level of access, from Team Member up to Manager, Owner, or operator, exactly like an employee. A vendor never logs in at all, so a vendor is always a Team Member and nothing more; a vendor record can't carry a login identity, and although it may hold an email address for reference, VERA never lets a vendor sign in.
The rate lookup is automatic and historical. If a team member's rate changed in October and you are looking at a September entry, VERA uses the September rate. Backdating an entry does not require any manual adjustment — the correct cost appears automatically.
This same historical lookup carries into your downloadable records. When you export your time data, every logged entry states what that hour of work cost using the rate in force on the day the work happened — not today's rate, and not a blended average. The export also shows the person's own pay rate alongside it, and for hourly work the two reconcile exactly: cost is hours × that rate, never adjusted by the employer cost multiplier. Each entry marks which basis produced its cost figure, so where a number is missing you know why. When an entry's cost genuinely can't be stated this way, VERA says so plainly instead of guessing: a vendor's fixed-fee work is a project-level, time-based figure rather than a per-entry one, so those rows are left blank with a note explaining why; the same is true for work recorded before any cost rate was ever put on record for that person. A blank is never a hidden zero — it is VERA telling you where to look elsewhere for the number.
What Happens When
Retainer burn — 40 hours per month, 30 hours logged with 10 days left
A client retainer's current period runs 30 days with a 40-hour budget. By day 20, the team has recorded 36 hours. Two thirds of the period has passed, so VERA expects about two thirds of the budget, roughly 27 hours. The team is at 90%, about 23 points ahead of plan. That evening and the next morning, the Owner and the project manager see the retainer named as off course. VERA judges the period the retainer is in, so a heavy last period cannot hide behind a light one before it. An underspend of the same size is flagged just as readily, because wasted retainer hours are wasted revenue. No manual calculation required.
Fixed-price progress — $20,000 contract, 60 of 100 hours logged
A fixed-price project has a $20,000 contract value and a 100-hour budget. The team logs its 60th hour. VERA immediately recognizes $12,000 in earned revenue — 60% of the contract value. The Owner's dashboard reflects the updated margin figure before the next morning's briefing. Nothing was invoiced; this is accrual. When the project closes at 100 hours, the full $20,000 has been recognized progressively across the life of the engagement.
Agile sprint accrual — $8,000 sprint, 30 of 40 hours logged
Sprint 3 of the Acme App project has a $8,000 contract value and a 40-hour budget. The sprint is marked active. The team logs 30 hours. VERA recognizes $6,000 in revenue: 30 ÷ 40 × $8,000. The remaining $2,000 accrues as the final 10 hours are logged. If the team logs a 41st hour, revenue stays capped at $8,000 and VERA flags the budget as exhausted. A new sprint with its own contract value is raised to accommodate additional scope.
Vendor with a fixed payment agreement — $4,000 agreed, 90 hours contracted
A design vendor is engaged for a fixed $4,000 on a campaign project running 10 weeks. The engagement covers 90 hours of design work. The vendor does not use VERA at all — nobody records time for them; the agreement carries their hours. Their cost is not $4,000 on day one. VERA accrues it evenly from the day the agreement was recorded to the project deadline: after 3 weeks of 10, $1,200 of cost has accrued (30%); after 5 weeks, $2,000 (50%); at the deadline, the full $4,000 is recognized. A fixed payment agreement to a vendor accrues evenly from the day we agreed it to the project's deadline — we don't pretend the whole cost has landed on day one. The agreement can instead run between dates you choose, and by default it runs between the project's start and its deadline, so an agreement recorded a week into the project has already accrued that week.
The vendor's 90 contracted hours follow the same shape. VERA cannot know the vendor's actual pace, so it assumes even delivery from the start date to the deadline: after 3 weeks, 27 hours (30%) are implied; after 5 weeks, 45 hours (50%); at the deadline, all 90 hours are counted. Both figures — hours and cost — grow at the same rate, keeping the P&L and the budget burn in sync. These implied hours are added to the team's logged hours when computing budget burn, health status, and proactive alerts. A project at 30% of its timeline shows 30% of vendor scope consumed and 30% of vendor cost accrued — the numbers tell the right story without the vendor logging a single entry.
What's the accrual basis right now? What will it be next Tuesday?
This is one of the more powerful things VERA can answer that a traditional time-tracking tool cannot.
A project has a Fixed Price contract for $10,000, a 100-hour budget, and a $2,300 fixed payment agreement with a design vendor running until the project deadline. Ten hours have been logged.
Today's accrual basis: Revenue recognized: $1,000 (10% of the contract, based on hours burned against budget). Vendor cost accrued: the design agreement was signed today, so roughly $0 of the $2,300 has landed yet — it accrues evenly from today to the deadline. Labor cost: hours × each person's rate on the date they worked. Net is revenue minus all costs.
In two weeks: Revenue is still $1,000 — no new hours have been logged, so nothing new has been earned. Vendor cost has grown proportionally: if the deadline is 70 days out and two weeks have passed, roughly 20% of the $2,300 has accrued. Labor cost is unchanged. Net has fallen slightly as vendor cost accrues without new revenue to offset it.
A month ago (past date): Revenue and labor cost reflect only what was on the books on that date — if no hours were logged yet, both are zero. This is useful for understanding what the P&L looked like at a specific milestone, or for reconciling a past report.
Future-date answers never extrapolate from pace. VERA only reports what is locked in — hours already logged plus the deterministic vendor cost accrual. It will not estimate how many hours the team might log between now and the date you asked about.
Backdated entry with a rate change — entry logged today for last month
A team member's cost rate increased on the first of the month. Today, that person logs time for a project meeting that took place three weeks ago. VERA looks up the rate that was in effect on the date of the meeting — the previous, lower rate — and applies it to the entry. The current rate is not used. The margin for that past period remains accurate without any manual correction.
Accrued P&L vs Forecasted P&L — two different questions
A project can look healthy to date yet be heading for a loss once the remaining allocated work is done.
Accrued P&L answers "where are we right now?" It shows revenue earned so far (based on hours logged against the contract or budget) minus cost incurred so far (hours logged at each person's rate on the date of the work, plus the portion of any fixed vendor agreement that has accrued to date). This is the same number that would appear in your books today.
Forecasted P&L answers "where will we land if everything goes to plan?" It holds revenue fixed at the project's full contracted value (for fixed-price work) or at the total allocated hours times the billing rate (for time-and-materials work), and sets cost equal to the full committed amount — every hour in every allocation, at current cost rates, plus every active agreed vendor fee in full. No pace is extrapolated; it is the worst-case-spend picture at close.
If the forecast shows a loss, the project detail page displays that as a red band spilling past the revenue line. A project that is 40% logged and reading "healthy" in the accrued view can simultaneously show a forecasted loss — meaning the team has already committed more cost than the contract will cover, even though the work hasn't been logged yet. That gap is the signal. Fixing it means either reducing the allocation before more time is logged, renegotiating scope, or understanding that the project is a deliberate loss-leader.
Forecast numbers are owner-only and only appear for fixed-price and time-and-materials projects. Retainer and agile projects are excluded in this version because their committed value lives on individual sprint or period records, not the project as a whole.
The morning briefing — what to record against, first
Every working morning, anyone who has hours allocated to them opens their briefing with those allocations laid out: each project and task they're expected to work on, how many hours were set aside, how many they've recorded so far, and how much remains. Anything they're close to using up — at or past 80% — is called out, and anything they've already overrun is flagged with how far over it is. The point is to lead with the forward-looking question — what should I be recording against today, and how much room is left — rather than a backward-looking tally of time already logged, which still appears, just lower down. Someone with no current allocations simply sees that recap of recent time. Owners and managers get the same personal briefing as everyone else, on top of the team-level pacing and approval summaries they already receive.
Managers and owners also get a short "at a glance" section: how last month went for money (owners only), which projects still need setting up or are off course, and who is over capacity this week. It is the same summary that opens the home page, worked out from the same figures, so the morning message and the screen never tell two different stories.
A project set up with the wrong type
If a project was set up as the wrong type, say a fixed-price job that is really a retainer, it can be switched without re-entering its time. Time already recorded against a retainer period always stays with that period, however many times the project is switched. The project's revenue is recalculated under its new type for its whole history, so the figures can change.
Lifecycles
Two processes in VERA have defined states. Understanding the allowed transitions prevents confusion about what the system will and will not do.
Time-off request
A team member submits a time-off request. It sits in a pending state — time is not logged, capacity is not affected. The Manager or Owner is notified immediately. On approval, the hours are logged automatically to the appropriate project and the team member is notified. No time is ever logged until a manager explicitly approves the request.
flowchart LR
A[Requested] --> B[Manager notified]
B --> C{Decision}
C -->|Approved| D[Hours logged<br/>automatically]
C -->|Declined| E[Request closed]Agile sprint
A sprint begins in "planned" status. No revenue is recognized and no hours budget is consumed. When the sprint is marked active, revenue begins accruing with every hour logged. The sprint does not move backward — once active, it remains active until the work is delivered. If the budget is exhausted before the work is done, a new sprint is raised to cover the remaining scope rather than silently overrunning.
flowchart LR
A[Planned<br/>$0 recognized] --> B[Active<br/>Revenue accrues with each hour]
B --> C[Closed<br/>All hours recognized]How VERA Follows the Conversation
VERA follows confirmations and follow-up questions within a working session, and always resolves who or what you mean from the people and projects mentioned in the conversation.
If you reply with "yes" or "1" after VERA offers a menu of options, it acts on your selection — no need to repeat the original request. If you ask "what about last week?" after an hours summary, VERA understands the reference without being told again. If you say "log her 3h" after mentioning a colleague, VERA resolves who you mean.
Each working day resets at midnight in your team's timezone. References to people and projects from earlier in the day carry forward; the day before does not.
The Point
These rules do not live in a handbook — they are built into every action VERA takes, every time entry, every revenue calculation, every morning briefing, every permission check. The sophistication is not in the interface; it is in the consistency.