Key takeaways
- Gravity is cloud accounting built on Microsoft Power Platform, aimed at multi-entity organisations.
- Its Bank Book pulls in bank and card activity through Plaid and Finicity and matches it.
- Transactions are tagged with dimension codes, which can be hierarchical, across entities.
- Vergo proposes entity, account and dimensions and posts entries into Gravity after your IT team enables access.
Where should you go next?
- Vergo's Gravity Software integration
- What expense management software integrates with Gravity Software?
- Get started with Vergo
How do you automate expense management in Gravity, step by step?
- Enable access. Gravity runs on Microsoft Power Platform, which has an open API; your IT team enables access once. Vergo then reads your chart of accounts.
- Connect the cards you hold today. Connecting your existing cards involves no card applications, no re-issuing and no banking change.
- Receipts by text. Employees handle everything by text message — no app to download, no portal login — and Vergo chases missing receipts itself instead of waiting for a report.
- Confirm entity, account and dimensions. Vergo proposes each from how similar spend was coded.
- Deliver to Gravity. Confirmed spend is posted as journal entries into Gravity, ready to match in the Bank Book.
What does Gravity need on each card purchase?
- Entity: which company in the group bought it.
- GL account.
- Dimension codes: location, department, fund or property, depending on your setup.
- Receipt for audit.
Where does Gravity stop and automation start?
The Bank Book imports card activity and matches it, and dimensions give powerful reporting once they are set. Setting them is the work: a card used by a family office manager may buy for three entities in a week. Vergo reads the receipt itself, line by line, and predicts the coding from what was actually bought, and proposes entity and dimensions together.
A practical example
A franchise group on Gravity runs six locations as separate entities. A district manager buys signage for one location and cleaning supplies for another on the same card. Vergo collects both receipts by text and proposes marketing for the first entity and location and janitorial supplies for the second, citing earlier purchases. The controller confirms, and both are delivered to Gravity coded to the right entity.
How Vergo handles this
Vergo proposes the coding by inference from your own accounting structure and history — no rule library to build, no keyword lists to maintain, and new vendors are coded on first sight. For multi-entity groups on Gravity, the entity is proposed first, because a cost in the wrong company creates intercompany clean-up. Approval workflows are optional and fit how you already control spend: route by GL account, by amount, or by project — or skip approval flows entirely and let policy flags catch only what breaks a rule. Card spend, employee reimbursements and AP invoices run through one coding model — same coding, same review, one reconciliation — and payment stays on the rails you already use.
Frequently Asked Questions
What does our IT team need to do?
Enable API access to your Gravity environment once. Vergo handles the rest.
Does Vergo post directly into Gravity?
Yes. Vergo posts journal entries into Gravity once access is enabled.
Can Vergo handle multiple entities?
Yes. Vergo proposes the entity with the account and dimensions.
Does this replace the Bank Book?
No. The Bank Book keeps importing and matching card activity.
Do we need new cards?
No. Connecting your existing cards involves no card applications, no re-issuing and no banking change.
