Businesses using G1.Honestly: not yet.

8 scenarios

• Illustrative scenarioManufacturing180 peopleTwo countries, one reporting currency

  Closing a four-company group in days, not weeks

  A four-entity manufacturing group

  A manufacturing group where consolidation happens in a spreadsheet nobody else can operate.

  AccountingConsolidationReportingControls & approvalsManagement accounting

  Read the whole scenario→

  The situation

  Each company keeps its own books in its own way. Consolidation is a spreadsheet built by one person over eleven years: intercompany balances are agreed by email, translation is manual, and the group pack arrives around the third week of the following month. When a number is questioned, answering takes a day.

  How G1 would be configured

  One chart of accounts and one dimension structure across all four entities, with separate books per company on a shared engine. Intercompany balances surface automatically instead of being reconciled by correspondence. Group statements come from the same ledger as entity statements, so a group figure drills straight through to the journal that created it.

  What it is designed to do

  • Designed so the group pack is produced from the ledger, not rebuilt from exports
  • Intercompany differences are visible during the period rather than at the end of it
  • Any consolidated figure drills to the entity, the document and the posting behind it
  • Adding a fifth entity is configuration, not a new spreadsheet

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.

• Illustrative scenarioProfessional services60 peopleSingle country, international clients

  Knowing project margin while the project is still open

  A professional services firm

  A consultancy that only learns which engagements made money after they have finished.

  ProjectsManagement accountingExpensesAccounts receivableAnalytics

  Read the whole scenario→

  The situation

  Time sits in one system, expenses in another, subcontractor invoices in the accounts, and the fee schedule in the contract. Project margin is calculated quarterly by hand. Work in progress is an estimate. Partners find out that an engagement went wrong when it is too late to renegotiate.

  How G1 would be configured

  Projects become a dimension stamped on every posting, so time, expenses and subcontractor cost land against the engagement as they happen. Budget, committed cost and actual sit on one record. Unbilled work is a ledger balance rather than a spreadsheet estimate.

  What it is designed to do

  • Built so cost lands against the engagement at the moment it is incurred
  • Work in progress and unbilled revenue readable at any point in the month
  • Margin by engagement, client and team from one definition
  • Overruns visible while there is still a conversation to have

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.

• Illustrative scenarioDistribution240 peopleThree countries

  Five systems, one customer, no agreement

  A distribution business

  A distributor where the same customer exists four times and nobody trusts the margin number.

  CustomersAccounts receivableSalesAnalyticsCash flow

  Read the whole scenario→

  The situation

  Orders come from a web store and a sales team, stock is managed in a warehouse system, invoicing happens in the accounts package and credit control runs on a spreadsheet. Every week someone exports and re-keys. Customer names differ across systems, so credit exposure is a manual exercise and margin by customer is an estimate.

  How G1 would be configured

  One customer record shared across the business, with credit limit and exposure on it. Sales data summarised into the ledger daily with the tax treatment applied once. The systems worth keeping stay and are connected; the manual bridges between the others are removed rather than automated.

  What it is designed to do

  • Designed around a single customer identity across every module
  • Credit exposure visible before the next order is released
  • Margin by customer, product and channel from one source
  • No weekly export-and-re-key step between systems

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.

• Illustrative scenarioHospitality310 people, mostly hourlySingle country, eleven sites

  Daily numbers for a business that reports monthly

  A multi-site hospitality operator

  A multi-site operator making daily decisions on data that arrives three weeks late.

  Management accountingCash flowAccounts payableDashboardsPayroll

  Read the whole scenario→

  The situation

  Eleven venues, one small central finance team. Takings, card settlement and supplier invoices all arrive at different times and in different formats. Labour and food cost as a percentage of revenue are known monthly, which is well after the week in which they could have been changed. Site managers work from their own spreadsheets.

  How G1 would be configured

  Every site on the same chart of accounts with its own dimension, so a site profit and loss is a filter rather than a rebuild. Card settlement reconciled against takings daily. Supplier invoices approved by the site that ordered, within a threshold set centrally.

  What it is designed to do

  • Built so site-level figures are available during the week, not after the month
  • Card settlement differences surface the next day instead of at close
  • Labour and cost of sales percentages comparable across every venue
  • Central overhead allocated on one agreed basis

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.

• Illustrative scenarioConstruction420 peopleSingle country, twelve live sites

  Knowing what a job will cost before it is finished

  A regional building contractor

  A contractor whose job costs are accurate the month after the decision that mattered.

  ProjectsProcurementAccounts payableManagement accountingCash flow

  Read the whole scenario→

  The situation

  Committed cost lives in a folder of subcontractor orders. Posted cost lives in the accounts. Variations are agreed on site and priced weeks later, and retention is tracked on a spreadsheet that only the commercial manager maintains. Cost to complete is a quantity surveyor's judgement, revisited monthly, and by the time a job is known to be losing money the remaining scope is already committed.

  How G1 would be configured

  Orders raise a commitment against the job as they are issued, so committed cost and posted cost sit on the same record. Variations are priced against the contract value rather than bolted on afterwards. Retention is a scheduled balance with a release date, not a note. Job costing reads from the ledger, so the surveyor's forecast and the accounts start from the same number.

  What it is designed to do

  • Committed cost appears the moment an order is raised, not when the bill lands
  • Cost to complete and contract value sit on one record, not two
  • Retention releases are scheduled and visible in the cash forecast
  • Margin erosion on a live job is visible while scope can still change

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.

• Illustrative scenarioFinancial services95 peopleTwo countries

  A close that survives being audited

  A regulated advisory firm

  A regulated firm whose controls exist in a policy document and nowhere in the system.

  Controls & approvalsComplianceAccountingDocumentsReporting

  Read the whole scenario→

  The situation

  Approval limits are written down and enforced by memory. Closed periods are reopened when a late invoice arrives, and the adjustment is made quietly. Posted documents can still be edited, so the audit trail is a best effort rather than a record. Every inspection begins with two weeks of assembling evidence that should already exist.

  How G1 would be configured

  Approval rules move into the database: the person who raises a document cannot release it, and the threshold is set by document type, amount and role. Periods lock, and reopening one is an event with a name attached. Posted records are immutable — a correction is a new document that references the original — so the audit trail is written by the system rather than reconstructed for it.

  What it is designed to do

  • Maker-checker is enforced where data is written, not in the interface
  • Period locks hold, and every reopening is recorded with who and why
  • Corrections are new documents, so the original stays readable
  • Evidence for an inspection is retrieved rather than assembled

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.

• Illustrative scenarioRetail640 peopleSingle country, 34 stores

  Thirty-four stores reconciled before opening

  A specialist retail chain

  A retail chain where card settlement, takings and the ledger agree only after a week of work.

  AccountingCash flowAnalyticsDashboardsAccounts payable

  Read the whole scenario→

  The situation

  Three card providers settle in batches on different days, net of fees. The till system exports takings in one format, the bank statement arrives in another, and someone matches them by eye. Differences are written off as timing until the month is closed, at which point nobody can say which store they came from.

  How G1 would be configured

  Takings post from the till summary with the tax treatment applied once. Settlement files are imported and matched by rule, with fees posted to their own account rather than netted into revenue. What does not match is an exception with a store, a date and an amount on it, raised the next morning instead of at month end.

  What it is designed to do

  • Settlement differences surface the next day, per store
  • Provider fees post as cost rather than disappearing into net revenue
  • Takings, settlement and the ledger reconcile by construction
  • Adding the thirty-fifth store is configuration, not another spreadsheet

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.

• Illustrative scenarioTechnology45 peopleSingle country, customers in nine

  Revenue that ties to the contract and to the cash

  A subscription software business

  A subscription business where recognised revenue, invoicing and the board pack disagree.

  ContractsAccounts receivableAccountingReportingAnalytics

  Read the whole scenario→

  The situation

  Contracts are signed in one system, invoiced from another and recognised in a spreadsheet that releases deferred revenue monthly. Annual prepayments make cash look better than trading. Renewals are tracked by whoever remembers, and the figures in the board pack are rebuilt each quarter from three exports that never quite reconcile.

  How G1 would be configured

  A contract creates its own billing schedule and its own recognition schedule, so invoicing and revenue come from the same record. Deferred revenue is a ledger balance that releases itself. Cash and recognised revenue are reported side by side rather than conflated, and renewal dates sit on the contract where the ledger can see them.

  What it is designed to do

  • Billing and recognition both come from one contract record
  • Deferred revenue releases on schedule instead of by journal
  • Cash and recognised revenue reported separately, on purpose
  • Board figures reconcile to the ledger without a rebuild

  Written as design intent, not as a measured outcome — there is nothing to measure yet, and we are not going to pretend otherwise.