> ## Documentation Index > Fetch the complete documentation index at: https://docs.invup.me/llms.txt > Use this file to discover all available pages before exploring further. # Core concepts > The handful of ideas that everything else in Invup is built on. Invup has about ten moving parts. Once you know what each one is for, the rest of the product explains itself. The short version: an **organization** does work for **clients**, organized into **projects**. Team members log **time entries** and **expenses** against those projects. Unbilled time and expenses become **invoices**. Money arriving against an invoice is a **transaction**. ```mermaid theme={null} flowchart LR O[Organization] --> C[Clients] C --> P[Projects] S[Services] --> P P --> T[Time entries] P --> E[Expenses] T --> I[Invoices] E --> I I --> X[Transactions] ``` ## Organization Your organization is the container for everything: your team, your clients, your work, and your money. It holds your business name, your logo, your address, and the settings that shape how the rest of the product behaves. Two of those settings matter more than the others, because they change how dates and numbers come out everywhere else. **Timezone** decides how every date and time in Invup is displayed, no matter where the person looking at it happens to be. A time entry logged at 9am in Vancouver reads as 9am to a colleague in Toronto when the organization runs on Pacific time. **Working days** records which days of the week your business operates. Daily time tracking prompts follow it. One person can belong to more than one organization, and switches between them inside the product. ## Team members and roles Everyone who works inside your organization is a **team member**. What they can see and do is decided by their **role**. | Role | What it is for | | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Owner** | Complete control, including transferring ownership and deleting the organization. Every organization has exactly one owner. | | **Admin** | Everything the owner can do, apart from transferring ownership and deleting the organization. | | **Member** | Day to day work: invoices, clients, projects, time entries, expenses. No access to organization settings, billing, or team management. This is the default for new invitations. | | **Contributor** | The narrowest role, for people who only log time. Contributors are managed through Slack and do not log in to Invup at all. | On the Pro plan you can also build custom roles and grant them exactly the permissions you intend. Roles decide access, not money. A contributor and an owner logging the same hour on the same project bill the same amount. ## Clients A **client** is a business or a person you invoice. The client record holds the billing details that appear on the invoice, along with the **contacts** who receive it. Contacts are the individual people at that client. Each contact has contact types that control which client facing emails reach them, such as invoices, reminders and receipts. A contact with no types set receives nothing, which is useful for someone you want on record but not in the mailing. Everything downstream hangs off a client. Projects belong to a client, and so do invoices. ## Projects A **project** is a body of work for one client. It is the thing time gets logged against: a case, an engagement, a build, a campaign, a retainer. Every project has a **type**: You bill for the time spent. Rates drive the value of the work. You bill an agreed sum for the whole job. Time is still tracked, but it measures effort rather than setting the price. Separately from type, a project can have **services enabled** or not. This is the single most consequential switch on a project, because it changes how rates are worked out. Projects also carry an optional budget, start and end dates, and a lock date. Locking a project up to a date stops members and contributors editing or deleting entries on or before it, which is what keeps a billed period from quietly changing underneath you. ## Services A **service** is a type of billable activity, describing the kind of work rather than who did it. Legal research. Site visit. Copywriting. Expert testimony. Services live in an organization wide library. You attach the relevant ones to each project that has services enabled. A service can be billable or non billable, and it carries a base hourly rate that other levels can override. Marking a service non billable is absolute. Any time logged against it is worth zero, regardless of every other rate you have set. ## Rates This is the part worth slowing down for, because it is where most of Invup's quiet intelligence lives. Nobody picks a rate when logging time. Invup works it out by walking a chain from the most specific rate it can find down to the most general, and the first rate it finds wins. Which chain it walks depends on whether the project has services enabled and whether the entry names a service. **Projects with services**, where the entry names a service: 1. This member, on this service, on this project 2. This member, on this service, anywhere 3. This service, on this project 4. The service's own base rate 5. The project's rate 6. The member's base rate for the organization **Projects without services**, and any entry that names no service: 1. This member, on this project 2. The project's rate 3. The member's base rate for the organization The practical consequence is that you should set rates broadly once and then override only the exceptions. A senior partner who bills at a special rate on one particular engagement needs one setting, not a policy. A rate of zero is a real answer, not a missing one. Setting a rate to zero at any level stops the search there rather than falling through to the next level. Alongside the chain sits the **rate lock policy**, an organization wide choice about when an entry's rate stops being able to move: | Policy | Effect | | --------------- | --------------------------------------------------------------------------------------- | | **At creation** | The rate is frozen the moment the entry is logged. Later rate changes never reach back. | | **At invoice** | The rate stays live until the entry lands on an invoice, and freezes then. | | **No locking** | The rate is always recalculated from current settings. | Whichever you choose, once an entry has been invoiced the amount you billed is the amount you billed. ## Time entries A **time entry** records that a team member did some work, on a date, on a project, for a duration. It can name a service, and it can be marked non billable. Each entry carries the rate that was resolved for it. Billable entries with no invoice attached are exactly what the invoice builder offers you when it is time to bill. ## Expenses An **expense** is money your business spent that you want to track, and often recharge. Expenses can be typed in, or captured by forwarding a receipt to an address that belongs to your organization, in which case Invup reads the receipt and fills in what it can. Expenses sit in categories, can be measured against budgets, and the billable ones can be pushed onto a client's invoice. ## Invoices An **invoice** is a bill sent to a client. It is assembled from **line items**, some pulled from unbilled time entries and expenses, some typed in directly, with taxes and discounts applied. How time collapses into line items is your choice. The same fifty hours can appear as a single line, one line per project, per service, per team member, or one line per individual entry, depending on how much detail that client expects to see. Invoices are numbered from a sequence you control, carry your default payment terms, and can chase themselves. Reminders go out on a schedule before the due date, and again once an invoice is overdue. For work that repeats, such as retainers and monthly fees, a **recurring invoice** is a template that issues a real invoice on a schedule. ## Transactions A **transaction** is money received against an invoice. Card payments made through the customer portal record themselves. Cheques, bank transfers and anything else that happened outside Invup get recorded by hand, so that the invoice reflects reality. ## The customer portal Your clients do not get an Invup login. They get a link. That link opens a portal showing their invoice, what it covers, and a way to pay it. It is the only part of Invup your clients ever see, which is why it is worth setting up your logo and payment options before you send the first one. ## Beyond the core Once the loop above is running, three further areas build on it. Send agreements for electronic signature, with payment schedules that can generate invoices. Collect structured information such as intake questionnaires and briefs, and keep the responses. See where time and money went, and have summaries emailed to you on a schedule. ## Next Put all of this to work by sending your first invoice.