How we bill
How we think about commercials and invoices in plain language — without publishing dollar rates on the web. The SOW & line-item decoder sits just below when AP wants contract wording mapped to typical rows; the invoice summary after that is what most teams start from for finance. Your real numbers live only in the proposal and contract we sign together.
What you can expect
- Project work is scoped in writing with estimates; most teams get a monthly invoice based on real time and deliverables logged that period, unless we agree a fixed price for a phase.
- Hosting and platform are usually a predictable base fee plus pass-through cloud and vendor costs, clearly listed.
- Usage (APIs, storage, processing) is metered against included allotments, with overage in arrears so there are no surprises at year-end.
- Support can be a plan with response targets, or simple hourly help outside that plan.
The decoder tables in the next section are optional — each row connects contract language to typical invoice lines (no dollar amounts on this page). Common questions (quotes, rates, cadence) sit in FAQs.
SOW language & typical invoice lines
Optional detail when you want to match contract paragraphs to line items. Nothing here is a quote; your signed documents control.
Project work
Statements of work spell out roles, deliverables, and whether a slice is time-and-materials or fixed-fee.
| Workstream | Often in the SOW / agreement | Typical invoice lines |
|---|---|---|
| Architecture & design | Design spikes, technical strategy, solution reviews, named milestones for discovery | Time by role or activity for the period (for example “Architecture”, “Solution design”) or a fixed milestone line when that phase was priced as a lump |
| Development | Features, APIs, integrations, acceptance criteria, sprint or phase boundaries | Time by role (“Engineering”, “Integration”) on a monthly rollup, or a fixed-fee line tied to the named release in the SOW |
| Project management | Delivery oversight, status reporting, risk tracking, stakeholder cadence | Same pattern as other project roles: time by role (“Project management”) on the period invoice so oversight is visible next to build time |
Hosting & platform
Fee schedules usually separate what we run for you every month from what the cloud meter says.
Base platform
| Tier | In schedule / SOW language | Typical invoice lines |
|---|---|---|
| Starter | Baseline hosting, monitoring, backups, agreed number of environments | One recurring “platform” or “managed service” line per billing cycle for the bundle |
| Growth | Higher limits, more environments, enhanced monitoring or alerting | Same recurring pattern, with the description updated to match the larger footprint you approved |
| Enterprise | Dedicated capacity, stricter runbooks, named coverage, custom SLAs | Recurring platform line plus any extra lines called out in the schedule (for example dedicated support windows) |
Cloud & vendor spend
| Cost type | In schedule / agreement | Typical invoice lines |
|---|---|---|
| Compute | References to cloud accounts, regions, instance families, or “pass-through infrastructure” | Lines that mirror the vendor usage report (often labeled with provider + service name) |
| Storage & bandwidth | Object storage, databases, egress caps, CDN, or similar bullets in the fee schedule | Separate lines per major meter so storage and transfer do not disappear into a single opaque total |
| Third-party APIs | Email, maps, identity, payments, or other SaaS keys we hold for you | Vendor charges as their own lines; if we agreed a separate administration fee, that appears as its own line too |
Usage (APIs, storage, processing)
Metering language lives in the fee schedule or product appendix: included amounts, measurement period, and how overage is calculated.
| Meter | In the schedule / SOW | Typical invoice lines |
|---|---|---|
| API calls | Included calls per month, definition of a “call”, rounding rules | Included bucket shown as part of the platform or usage bundle; overage as a separate “API overage” (or similar) line on the next cycle |
| Storage | Included gigabytes, how snapshots or replicas count | Included allowance rolled into platform or storage line; incremental storage as its own line when you cross the threshold |
| Processing | Jobs, worker hours, credits, or other units defined for your product | Line items tied to that unit (“Processing overage”, “Job queue”) so engineering can match logs to the bill |
Support & maintenance
Support tiers are usually an exhibit or table in the agreement: channels, hours of coverage, and first-response targets.
| Plan | In the agreement | Typical invoice lines |
|---|---|---|
| Basic | Email channel, business-hour coverage, first-response window | Often bundled into the platform line when the SOW says support is included; otherwise a small recurring “support” line |
| Standard | Priority queue, faster first response, named escalation path | Recurring “Support — Standard” (or similar) each cycle while the plan is active |
| Premium | Tighter windows, shared chat or bridge line, optional after-hours coverage | Recurring line for the tier; any after-hours add-on called out separately if the schedule says so |
| Outside the plan | Change requests, investigations, or training not covered by the tier | Time-and-materials lines with the role and date range; minimum increment spelled in the SOW shows up as the billing granularity on the invoice |
Formal uptime credits or data-processing roles appear in SLA / DPA attachments, not buried in a generic support paragraph.
Add-ons & optional work
Optional work is either a change order to the SOW or its own short statement.
| Add-on | In the SOW / change order | Typical invoice lines |
|---|---|---|
| Extra environments | Additional staging or dev stacks, run duration, who operates them | Recurring per-environment line for each month they stay provisioned |
| New integrations | Named systems, auth model, test plan, go-live window; T&M or fixed fee | Time by role during build, or a milestone-based line for a fixed integration fee |
| Data migration | Source and target, cutover date, validation steps, rollback plan | Project fee line for the migration window; ongoing sync as its own line if you kept that in scope |
| Reporting & analytics | Dashboards, refresh cadence, data sources, who maintains queries | Build time during implementation; optional recurring “reporting ops” line if we host or refresh for you |
How often you pay
Payment rhythm and consequences are in the MSA or order form, not inferred from email.
| Topic | Where it is written | What you should expect |
|---|---|---|
| Invoice cadence | Billing frequency clause or fee schedule header | Most engagements invoice monthly for that period’s lines; anything different is called out explicitly |
| Payment due | Net terms in the MSA or order form (for example net fifteen or net thirty) | Each invoice shows the due date AP should use; it matches what you signed |
| Late payment | Remedies section: fees, interest, or right to pause work | If something is late, what happens next follows the contract — not a one-off note on a random page |
When fees change
Tier changes and rate updates should match the change / notice section of your agreement.
| Situation | In the agreement | What usually happens |
|---|---|---|
| Rate or tier adjustment | Notice period, effective date, and whether usage tiers reset | You receive written notice first; invoices after the effective date reflect the new tier or rate table |
| Upgrade | How to request more capacity or a higher support tier | Takes effect on the date the schedule says (often quickly) so you are not blocked when traffic jumps |
| Downgrade | Cancellation or reduction terms | Typically aligns to the start of the next billing cycle so partial-month confusion is avoided |
Words we use on invoices
These terms bridge legal / product language and the line your AP team sees.
| Term | Where you see it | Plain meaning |
|---|---|---|
| Usage | Fee schedule, product appendix, or metering addendum | Metered consumption we count each cycle (calls, storage, processing, and similar) |
| Billing cycle | Fee schedule or MSA definitions | The window we use to add up recurring and metered lines — usually a calendar month unless otherwise stated |
| Overage | Same as usage section; often a table of included vs excess | Anything above the included amount for that cycle, billed on the next invoice after measurement closes |
Reading a month-end invoice
A single month is usually a stack of named lines, each traceable back to a paragraph or table in your documents — not one unexplained total.
| Line you might see | Trace it to … | What it represents |
|---|---|---|
| Platform / managed service | Fee schedule “base platform” section, SOW environment list | The steady cost of running what we agreed to operate for you this cycle |
| Cloud provider (named service) | Pass-through or infrastructure exhibit; vendor invoice attachment | Metered spend from the provider’s bill, broken out so finance can reconcile to the vendor statement |
| Support tier | Support exhibit in the agreement | The response-time and channel package you have enabled for the period |
| Professional services (by role) | SOW roles, rates appendix if you have one, timesheet or worklog export | Time logged against the project during the invoice window |
| Usage overage | Included vs overage table in the fee schedule | Traffic, storage, or processing above the included threshold for that cycle |
Still need numbers for your org? Use Signal on Contact.
What usually shows up on an invoice
Every engagement has its own SOW, fee schedule, and order form. In practice, most monthly bills roll up into a few clear buckets finance can map to GL without guessing.
- Project & delivery — Engineering, architecture, PM, and integrations: time by role each cycle, or fixed-fee milestones when a phase was priced as a lump.
- Platform / managed service — A recurring line for the operating bundle we agreed to run (environments, monitoring, backups, baseline coverage).
- Pass-through infrastructure — Cloud and vendor meters as separate lines (compute, storage, bandwidth, third-party APIs) so nothing hides inside an opaque total.
- Usage & overage — Included allotments for calls, storage, or processing; anything above the threshold hits as its own overage line on the next invoice after the window closes.
- Support — When not folded into platform, a recurring line for the tier you selected (channels, coverage, first-response targets).
- Add-ons & change orders — Migrations, extra environments, net-new integrations: either project time or a named milestone line, exactly as written in the change order.
Cadence, net terms, and tier changes are covered in FAQs.
Need a written fee list for your org? We do not publish dollar rates or rate cards on the web. Send scope and stack through Signal on Contact and we will reply with something you can run past finance and procurement.
Request pricing listQuestions finance and product teams ask
Short answers here; the sections above stay scannable. Nothing below replaces your signed proposal, order form, or MSA.
Is anything on this page a quote or binding rate card?
No. Nothing here is a quote. When we work together, the fees and cadence in your written proposal and contract are the ones that apply.
Subscribed software from us is covered separately under the product terms of service.
Why do you not publish dollar rates on the web?
Rates depend on stack, traffic, models, compliance, and how much of the footprint we operate. Publishing a generic table misleads more than it helps. We send written fees when scope is real — use Signal on Contact with your situation.
What costs do not show up on a cloud or SaaS vendor invoice?
None of the following is usually a separate line on a hosting provider’s bill — but finance and leadership still pay for it, often as payroll, risk, or delayed roadmap work.
- Platform engineering — provisioning, upgrades, incident bridges, on-call rotation, and postmortems across multiple providers when something spans layers.
- Security and access — patching cadence, credential hygiene, log review, and evidence gathering when you need to show how production is controlled.
- Usage and spend hygiene — reading every metered bill, chasing anomalies, rightsizing, and deciding what to cache or gate before usage silently doubles.
- Vendor administration — separate contracts, tax artifacts, renewal dates, support tickets, and the time spent when two vendors each insist the root cause is the other side.
- AI-heavy products — model and tool choices can swing monthly spend far more than a single server tier; tuning prompts, batching, and fallbacks is ongoing work, not a one-time setup.
What does a self-managed footprint usually look like?
Typical pattern: many relationships (each with its own console, invoice, and support queue), many recurring bills to reconcile, and no single owner when an outage cuts across frontend, API, data, cache, email, and third-party intelligence APIs.
How do you structure the alternative when you operate our stack under contract?
In a managed engagement we aim for one commercial relationship for the operating model we agree in writing: clear platform and support lines on your side of the ledger, pass-through infrastructure spelled out so meters stay visible, and one escalation path when something breaks — we coordinate the underlying providers instead of your product team doing it ad hoc.
How do billing cycles, tier changes, and net terms usually work?
Cadence and net terms come from the MSA. Tier upgrades or rate changes follow the notice rules in your agreement, usually aligned to billing-cycle boundaries for downgrades. Exact language is always in your order form and fee schedule.
Want specifics?
Request a pricing list through Signal with your product, systems, and timeline — we will reply with fit, approach, and written fees when it makes sense. If you are already working with us, invoice links live in the client billing area of the hub. More on delivery: Services.