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 — distribute hours, approve time off, monitor burn rates — without ever seeing a dollar figure. 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 utilisation 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.
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 and Agile projects are supported for existing engagements — reporting, status checks, and dashboards all work as described below. New retainer and agile projects are not currently available; T&M or Fixed Price cover the same use cases 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 what your people have actually earned 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.
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 a 5:1 efficiency target). For a $100,000 project, 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 labour. 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. If the project also has vendor commitments, those are added to the committed total, the panel header changes to "Envelope and liability budget", and the bar splits into two colours — one for envelope cost, one for vendor cost — so you can see the source of the commitment at a glance. 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.
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.
| Situation | Cost calculation |
|---|---|
| Employee or contractor logs time | Hours × the cost rate in effect on the date of the entry |
| Vendor with a fixed payment agreement on the project | Pro-rata portion of the agreed amount — accrues linearly from agreement date to project deadline |
| Vendor without a fixed payment agreement | Hours × the cost rate in effect on the date of the entry |
Fixed payment agreements are reserved for vendors. A contractor cannot have one — VERA will refuse to create it. The reasoning is operational: contractors are inside the system, accumulating hours toward an allocation, and a fixed-fee shortcut would silently make those hours invisible to the cost engine. If a contractor genuinely needs a fixed-fee deliverable, the right move is to set them up as a separate vendor record for that engagement and let the two roles live side by side.
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.
What Happens When
Retainer burn — 40 hours per month, 30 hours logged with 10 days left
A client retainer is contracted at 40 hours per month. By day 20 of a 30-day month, the team has logged 30 hours. VERA calculates a burn rate of 1.5 hours per day and projects 45 hours by month end — five hours over budget. The next morning, the Owner and Manager see a critical overspend alert: "Pacing to exceed retainer by 5 hours. Reduce activity or flag scope to client." A week earlier the same engine would have caught an underspend just as readily — 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 — the project manager logs time on their behalf. 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 recognised. 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 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 recognised: $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. Labour 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. Labour cost is unchanged. Net has fallen slightly as vendor cost accrues without new revenue to offset it.
A month ago (past date): Revenue and labour 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, 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 the 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.
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.
mermaid
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.
mermaid
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.