Migrating from the QuickBooks P&L

If your platform currently reads a Profit & Loss report per business out of QuickBooks Online, the summary endpoints are the drop-in replacement. This page maps the fields, then covers the three things that are genuinely different.

The mapping

Every value below comes from the totals object on /financial_reports/income_statement/summary (one range) or on each period of /financial_reports/income_statement/monthly/summary (one column per month).

QuickBooks P&L field	Flychain field
Income	operating_revenues_cents
COGS	cost_of_goods_sold_cents
GrossProfit	gross_profit_cents
Expenses	operating_expenses_cents
NetOperatingIncome	total_operating_profit_cents
OtherIncome	other_income_cents
OtherExpenses	other_expenses_cents
NetIncome	net_profit_cents
NetOtherIncome	net_other_income_cents

net_other_income_cents is returned directly rather than left for you to derive. It is other_income_cents minus other_expenses_cents, and it is the one figure in this mapping with no direct equivalent in our own statement — we compute it so both sides of the migration agree on it by construction rather than by convention.

Three real differences

1. Amounts are integers in cents

QuickBooks reports decimal strings; we return signed integers in cents. 3642500 is $36,425.00. Multiply by 100 on the way in, or better, keep cents throughout — that is why we expose them this way. Do not round-trip a figure through a float.

2. There is one revenue figure to choose, and one extra one to ignore

operating_revenues_cents is gross revenue and is the direct counterpart of QuickBooks’ Income. If your calculation is revenue-based, this is the field.

We also return total_net_sales_cents, which QuickBooks does not produce: operating revenue net of refunds, discounts and write-offs. For most entities it equals operating revenue exactly; where it differs, it is the more conservative measure. It is offered as a choice, not a replacement — a revenue-linked calculation that switches to it changes the figure, so switch only deliberately.

3. No per-business authorization

The QuickBooks integration needs an OAuth grant per company, so each new business is a setup step involving both sides. Here, a single key covers every business in your partner relationship and a new one appears in GET /business_entities on its own. See Authentication.

Suggested cutover

Reconciliation before dependency, per business:

1. Discover. Pull GET /business_entities and match each record against your own records. ein is the field to match on, since books — and therefore every report — are kept per legal entity. Note books_start_date: it bounds how far back a comparison can go (see Data semantics).
2. Parallel run. For a business live on both systems, pull the same period from both and compare field by field. Use a closed period — one where is_closed is true — so you are comparing two settled figures rather than chasing a provisional one.
3. Cut over business by business as each moves onto Flychain, rather than all at once.

If a closed period disagrees between the two systems, tell us the entity, the period and both figures. A discrepancy on closed books is something we want to explain, not something to work around in a mapping layer.

What you also get

Two things worth using once the mapping works, because they remove logic you currently carry:

• One request per business for a trailing window. monthly/summary returns every month in a range, each labelled and flagged, so a twelve-month reconciliation is one call rather than twelve.
• Explicit close flags. is_closed per period replaces inferring from the calendar whether a figure is final. Data semantics covers how to use it.