Stop rebuilding the same
report every month
Rig pulls from Stripe, Xero, QuickBooks, NetSuite and your CRM, applies the definitions you agreed once, and builds the pack itself
"Build the board pack for last month"
Pack assembled, variances flagged
Every figure traceable to the rows behind it
Finance is the team most likely to be doing data engineering by hand
The systems that hold the answer are all connected to each other by a person. The ledger knows what was booked, the CRM knows what was sold, billing knows what was collected, and reconciling the three is somebody's week, every month, forever.
- The same pack rebuilt by hand each cycle, because nothing assembles it
- Two teams reporting different revenue because nobody certified which definition wins
- Overdue invoices chased from a list somebody exported on Monday
- A board question that takes three days because it needs data from four systems
- Model errors nobody catches, because nothing checks the tracker against source
We run our own investor reporting this way
Roughly 120 monthly investor reports over ten years, first at Lingumi and now at Rig, assembled from finance, contracts, product analytics, CRM, calls and banking data rather than from a spreadsheet somebody updates the night before.
Investors sit in a governed Slack channel with role-based restrictions on what they can see. One of them pulled the status of a live deal, found a way to help move it along, and did it without a founder in the loop.
// Built on Rig
Apps Finance teams build on Rig
Real examples assembled from Rig's building blocks. Hover to see how each works, then build your own version for your exact workflow.
Quote-to-cash & invoicing
Automate the path from closed-won to cash collected
A workflow that picks up every closed-won deal, raises and reconciles the invoice across CRM, billing and your ledger, and chases what is overdue.
Investor & board reporting
Auto-assemble the board pack from source data
Generate the monthly board and investor update straight from finance, product and CRM data, with the numbers and commentary built in minutes, not days.
Common questions
From the source systems, every time it runs. Rig connects your billing, ledger, CRM, product and banking data, you define each metric once in the context layer, and the pack assembles from those definitions rather than from last month's spreadsheet with the dates changed. If a number moves, you can click through to the rows behind it.
You do not have to. Most finance teams keep the model they trust and use Rig to feed and check it. Suri's team used their existing monthly finance tracker as an eval set: Rig rebuilds each metric, scores it against the tracker, and only definitions inside the error boundary go to a human. That caught errors in the tracker as well, including SKUs with no cost of goods and costs booked into revenue that did not belong there.
A BI tool renders a chart and stops. Rig goes on to do the thing: assemble the pack, chase the overdue invoice, write the updated figure back into the CRM, post the weekly summary into Slack, on a schedule or on a trigger. It also keeps its own context current as your chart of accounts and schema drift, which a hand-maintained semantic model does not.
Yes, that is the normal setup. Access is role based per person and per agent, so finance sees the ledger and a rep sees their own accounts. Queries run in a sandbox rather than against the raw database and every one is logged, which matters when the same layer is serving your auditors and your AI tools.
The usual first win is a single recurring report that currently eats a day a month. Connect its sources, certify the handful of metrics it depends on, and schedule it. Broader rollouts take longer because agreeing definitions takes longer than moving data, which is the honest constraint on every project of this kind.
Stripe, Xero, QuickBooks, NetSuite, Ramp, Mercury and Revolut Business are in the catalogue, alongside the CRM, support, ads and product sources you need to explain a number rather than just report it. Anything not listed can come in via the integrator or webhooks.