The CFO’s Guide to SaaS KPIs, Metrics, and Dashboards

June 25, 2026 15 min read

Cash Flow Report

A Complete Step-by-Step Guide with Functional & Technical Specifications

A Note on Our Previous Approach

https://satvasolutions.com/blog/xero-cash-flow-report-without-api

We previously explored a different method for generating a Cash Flow Report from Xero data.

During implementation, we identified some limitations with that approach and moved to a revised solution.

This article describes the approach that was ultimately implemented and produced the desired results.

Chapter 1: Understanding the Big Picture

Every business, big or small, needs to know one fundamental truth at the end of each month: where did the money actually go and where did it come from? Not profit on paper.

Not figures on invoices. Real cash, moving in and out of bank accounts.

This is exactly what a Cash Flow Report tells you. Unlike a Profit & Loss statement, which records income when it is earned and expenses when they are incurred, the Cash Flow Report tracks only actual cash movements.

If you raised an invoice but the customer has not paid yet, that money does not appear here. If you paid a supplier by bank transfer, it does.

This guide walks you through the complete journey from raw accounting data in a system like Xero, all the way to a clean, structured Cash Flow Report that your finance team and stakeholders can rely on.

It is both a business explainer and a technical blueprint.

What Does a Cash Flow Report Actually Show?

A well-structured Cash Flow Report is divided into four key sections, each telling a different part of the money story:

Section	What It Tracks	Simple Question It Answers
Operating Activities	Day-to-day business cash – receipts from customers, payments to suppliers and employees.	Are we making cash from running the business?
Investing Activities	Cash spent or received from buying/selling long-term assets like machinery or property.	Are we investing wisely in our assets?
Financing Activities	Cash from owners, loans, or repayments – equity and debt movements.	How are we funding the business?
Cash & Cash Equivalents	Opening balance, net change during the month, and closing balance.	How much cash do we actually have?

Chapter 2: Where the Data Comes From

Before we can build anything, we need to understand what data feeds the report.

This is where accounting platforms like Xero come into the picture. Xero provides a set of well-structured APIs that give us everything we need account definitions and cash journal entries.

Think of it in two layers. The first layer is the Chart of Accounts, a master list of every financial category the business uses, from revenue accounts to fixed asset codes.

The second layer is the Journal Entries, the transactional heartbeat of the system, recording every single financial event as it happens.

The API Endpoints That Power Everything

API Endpoint	Data Provided	Why It Matters
/Accounts	Chart of accounts	Gives us account categories, types, and reporting codes the classification engine.
/Journals?paymentsOnly=true	Cash-based journal entries	Filters to only real cash movements – no accruals, no estimates.

The critical filter here is paymentsOnly=true on the Journals API. This single parameter is the most important decision in the entire data pipeline.

It ensures we are capturing only transactions that resulted in actual cash changing hands not accounting adjustments, depreciation entries, or unrealised figures.

KEY INSIGHT

The difference between a cash flow report and a P&L is this filter. Without paymentsOnly=true, you get accounting entries. With it, you get real cash movements. Always use it.

Chapter 3: Step-by-Step: Syncing the Data

Now the journey begins in earnest. Data from Xero needs to find its way into our own database, where we can control it, query it, and build reports on top of it. This happens in two clean, sequential steps.

Step 1 Sync the Chart of Accounts

The first step is to pull a fresh copy of all accounts from Xero into our local Account table. This is the foundation that everything else depends on, because every journal line references an account.

Call the GET /Accounts endpoint and map the response fields to the target table columns. This sync should run once daily, or whenever your finance team makes a change to the chart of accounts in Xero.

Xero API Field	Target Database Column
AccountID	AccountID (Primary Key)
Code	Code
Name	Name
Class	AccountClassTypes (REVENUE, EXPENSE, ASSET, etc.)
Type	Type (e.g., FIXED, CURRLIAB)
ReportingCode	ReportingCode

Step 2 Sync the Cash Journals

With accounts in place, the second step is to pull journal entries. Use GET /Journals?paymentsOnly=true to retrieve all cash-based journal lines and insert or update them in the JournalLineCash table.

For each journal returned by the API, extract and map the following:

JournalDate, JournalNumber, and JournalLineID for timeline and identification
AccountID, linking every line back to the Account table
GrossAmount, NetAmount, TaxAmount, Debit, and Credit for financial values
SourceType this is the transaction classifier (e.g., CASHPAID, ACCRECPAYMENT)

The SourceType field deserves special attention. It is the field that tells us why this cash movement occurred was it a customer payment, a supplier payment, or a bank transaction? The report logic depends heavily on this classification.

SYNC FREQUENCY

Run the Accounts sync daily. Run the Journals sync nightly for most businesses, or hourly for high-volume transaction environments. Always use incremental sync to avoid re-processing old data.

Chapter 4: The Database: Designing for Accuracy

Good reporting starts with good data structure. The two core tables Account and JournalLineCash are designed to be lean, well-indexed, and perfectly aligned with the Xero data model.

Table 1: Account

This is the classification master table. Every account in Xero maps to one row here. The most important columns for cash flow classification are AccountClassTypes, Type, and ReportingCode.

Column	Data Type	Description
AccountID	uuid	Primary key unique identifier for each account.
Code	varchar(10)	Short account code (e.g., 400 for Sales).
AccountClassTypes	varchar(50)	High-level category: REVENUE, EXPENSE, ASSET, LIABILITY, EQUITY.
Type	varchar(50)	Detailed type: FIXED, CURRLIAB, DIRECTCOSTS, etc.
ReportingCode	varchar(200)	Standard code (e.g., ASS.NCA.FIX.PLA) used for precise filtering.
CurrencyCode	varchar(50)	Currency of the account – INR, USD, GBP, etc.
CompanyId	uuid	Links account to the correct company in multi-tenant systems.
TenantId	varchar(100)	Xero’s tenant reference for multi-org setups.

Table 2: JournalLineCash

This is the transactional core every cash journal line lives here. It references the Account table and carries the financial amounts needed for every report calculation.

Column	Data Type	Description
Id	uuid	Primary key for each journal line.
JournalDate	date	Date the transaction occurred core for monthly grouping.
SourceType	varchar(30)	Type of transaction: CASHPAID, ACCRECPAYMENT, CASHREC, etc.
AccountID	uuid	Foreign key linking to the Account table.
GrossAmount	numeric(18,2)	Amount including tax used for Operating and Financing.
NetAmount	numeric(18,2)	Amount net of tax used for Investing (asset purchases/sales).
TaxAmount	numeric(18,2)	Tax portion of the transaction.
CompanyId / TenantId	uuid / varchar	Multi-company and multi-tenant identifiers.

INDEXING TIP

Always add a composite index on (CompanyId, JournalDate) for the JournalLineCash table. This single index dramatically speeds up monthly report generation across multi-company environments.

Chapter 5 Business Logic: Classifying Every Transaction

This is where the intelligence of the report lives. Not every transaction belongs to the same section. A payment to a supplier is an Operating activity. Buying a new machine is an Investing activity.

A loan from the owner is Financing. The classification logic uses three fields SourceType, AccountClassTypes, and ReportingCode in combination.

Operating Activities

Receipts from Customers

Cash actually received from customers for goods or services sold. These are inflows.

SourceType must be one of: ACCRECPAYMENT, ACCRECCREDIT, or CASHREC
AccountClassTypes must be REVENUE, AccountType must be REVENUE
Amount used: GrossAmount (inclusive of any tax)

Payments to Suppliers and Employees

Cash paid out to vendors, suppliers, or as staff salaries. These are outflows.

SourceType must be one of: CASHPAID, ACCPAYPAYMENT, EXPPAYMENT, ACCPAYCREDIT, or ARCREDITPAYMENT
AccountClassTypes must be EXPENSE
Amount used: GrossAmount

Other Operating Receipts and Payments

Smaller operational items like interest income refunds or minor exchange losses. Interest income uses TaxAmount if AccountType is FIXED; otherwise GrossAmount.

Minor losses use GrossAmount with reporting codes EXP.FOR.UGL or EXP.FOR.RGL.

Investing Activities

Proceeds from Sale of Property, Plant & Equipment

Cash received from selling long-term physical assets machinery, vehicles, buildings. AccountClassTypes: ASSET, Type: FIXED, ReportingCode matches ASS.NCA.FIX.PLA.%. Amount used: NetAmount.

Payment for Property, Plant & Equipment

Cash paid to acquire new long-term assets. Same classification as above but represents outflows. ReportingCode is ASS.NCA.FIX.PLA or ASS.NCA.FIX.OWN.PLA. Amount used: NetAmount.

Other Investing Items

Other asset-related cash movements such as security deposits. AccountClassTypes: ASSET, ReportingCode contains ASS.CUR. Amount: GrossAmount.

Financing Activities

Cash movements related to owners or lenders contributions, loan drawdowns, or repayments. AccountClassTypes must be LIABILITY or EQUITY, Type must be CURRLIAB, and the ReportingCode must not be TAX. Amount used: GrossAmount.

The Calculation Formulas

Section Net	Formula
Net Operating Cash	Receipts from customers + Other inflows Payments to suppliers Other payments
Net Investing Cash	Proceeds from PPE sales + Other inflows PPE purchases
Net Financing Cash	All financing inflows All financing outflows
Net Cash Flow (Period)	Net Operating + Net Investing + Net Financing
Cash at End of Period	Cash at Beginning of Period + Net Cash Flow for Period

Chapter 6: The SQL Layer: Aggregation & Views

Once the data is synced and classified, the database does the heavy lifting. Two layers of SQL logic transform raw journal lines into a clean monthly cash flow statement.

Layer 1 Stored Procedure for Pre-Aggregation

The stored procedure runs monthly (or on-demand) and pre-computes cash flow totals per company per month.

By grouping JournalLineCash by CompanyId and Month(JournalDate), and applying the classification logic (SourceType, AccountClassTypes, ReportingCode), it produces summary figures that the reporting layer can serve instantly.

Pre-aggregation is an important design choice. Without it, every time a user opens the report, the database would need to scan and classify potentially thousands of journal lines in real time.

The stored procedure does this work once, overnight, and caches the results.

Layer 2 PostgreSQL View: cash_flow_statement_monthly_all_companies

The main reporting view sits on top of the aggregated data and brings it all together. It is the final SQL layer that any application, dashboard, or export tool reads from. Key design highlights of this view include:

Uses recursive CTEs to generate a continuous monthly date range – no gaps even in months with zero transactions
Joins JournalLineCash with the Account table to access ReportingCode and AccountClassTypes for every line
Uses CASE conditions to sum each cash flow category separately – receipts, payments, investing, financing
Calculates cumulative EndCash using a running SUM(NetCashFlows) OVER (ORDER BY month) window function
Derives BeginCash as the prior month’s EndCash sensuring perfect continuity across periods

AMOUNT RULES

Operating & Financing sections use GrossAmount (tax-inclusive). Investing section uses NetAmount (tax-exclusive). This distinction matches standard IAS 7 cash flow presentation requirements.

Chapter 7: End-to-End Flow & Final Output

Let us now trace the complete journey of a single transaction through the entire system from the moment it happens in the real world to the moment it appears on the Cash Flow Report.

Step	Source	Target	Example
1	Xero Accounts API	Account Table	AccountClassTypes: EXPENSE, Code: 400, Type: DIRECTCOSTS
2	Xero Journals API	JournalLineCash Table	JournalDate: 2025-10-15, SourceType: CASHPAID, GrossAmount: 6,300.00
3	SQL Stored Procedure	Aggregated Monthly Totals	NetOperating: −7,187.38, NetInvesting: −6,300.00
4	PostgreSQL View	Final Report Dataset	All sections with BeginCash, EndCash, and NetCashFlows per company per month
5	Application / Dashboard	Cash Flow Report UI or PDF	Cash Flow Report for October 2025 – ready for finance team

The Final Report What Finance Sees

After all the data pipeline steps are complete, here is what the finished report looks like for a sample period:

Section	Line Item	Amount
Operating	Receipts from customers	₹8,307.00
Operating	Payments to suppliers & employees	−₹14,961.43
Operating	Other receipts / payments (net)	₹532.95 / −₹100.00
	Net Cash from Operating Activities	−₹7,187.38
Investing	Proceeds from sale of PPE	₹10,000.00
Investing	Payment for PPE	−₹6,300.00
	Net Cash from Investing Activities	−₹6,300.00
Financing	Other financing items (owner contribution)	+₹1,507.00
	Net Cash from Financing Activities	+₹1,507.00
	NET CASH FLOW FOR PERIOD	−₹11,980.38
Cash Position	Cash at Beginning of Period	₹924.29
Cash Position	Cash at End of Period (Overdraft)	−₹11,056.09

Maintenance, Validation & Best Practices

A cash flow report is only as good as the data that feeds it. Once the system is live, maintaining data quality and pipeline reliability becomes the ongoing priority.

The following practices should be embedded into your operations from day one.

Sync & Performance

Run the Accounts sync daily changes to the chart of accounts are infrequent but critical when they happen
Run the Journals sync nightly for most businesses; increase to hourly for high-volume operations
Always use incremental sync track the last synced JournalDate and only pull newer records
Add a composite database index on (CompanyId, JournalDate) on the JournalLineCash table this is non-negotiable for performance

Data Validation

Validate that every JournalLineCash.AccountID maps to a valid Account.AccountID before inserting
Skip journals without valid AccountClassTypes and write them to an error log for manual review
Cross-check monthly EndCash totals against Xero’s own bank reconciliation figures as a sanity check
Flag any SourceType values not in the known classification list these indicate new transaction types that need mapping

Error Handling

Never silently discard failed records log every skipped journal with its JournalID, reason, and timestamp.

Build a monitoring alert for sync failures a missed nightly sync means stale report data
Maintain a mapping table for SourceType to report section, so new transaction types can be classified without code changes

Summary of Deliverables

To build this system end to end, five deliverables are needed:

Database Tables : Account and JournalLineCash, with correct types and indexes
Data Sync Services : Scheduled jobs for Accounts API and Journals API (paymentsOnly)
Stored Procedure : Monthly pre-aggregation per company, per section
PostgreSQL View : cash_flow_statement_monthly_all_companies, the final reporting layer
Business Report : UI dashboard or PDF export for finance teams and stakeholders

This architecture ensures accurate, scalable, and audit-ready cash flow reporting.

Cash Flow Account Mapping Approach

Chapter 8 What Problem Are We Actually Solving?

Imagine you have been using Xero to run your business for a few years. Your bookkeeper has entered hundreds of transactions, set up custom accounts that made sense for your business, and everything looks tidy inside Xero itself.

Now you connect Xero to a reporting tool and ask it to generate a Cash Flow Report. You expect the numbers to match what you see in Xero.

But they do not. Totals are off. Some lines are wrong. A few transactions sit in an “Uncategorised” bucket that nobody knows what to do with.

This is the exact problem we are solving. And understanding why it happens is the first step to fixing it properly.

Why Does the Mismatch Happen?

A Profit & Loss report and a Balance Sheet are relatively straightforward to generate from Xero data. The rules are clear and consistent. But a Cash Flow Report is different it is more subjective.

The same transaction can legitimately belong to different sections depending on the context of the business.

THE CORE ISSUE

Cash flow classification is not just about what an account is called. It is about what that account means for your specific business and that varies from one organisation to the next.

The classic example is the account called “Donations.” Three businesses, three completely different classifications:

Business	How They Use Donations	Cash Flow Classification
A church	Donations are their main income – money coming in from members.	Operating Inflow (income)
A school	Donations received are used to buy computers and equipment.	Investing Outflow (asset purchase)
A regular business	They donate to charity as a business expense.	Operating Outflow (expense)

Same account name. Three completely different meanings. No automated system can guess this correctly every single time which is exactly why some accounts end up misclassified or uncategorised in the final report.

Chapter 9: Why Standard Accounts Are Easy, Custom Ones Are Not

When we test the system using a Xero demo company, things usually look great. The numbers match up, the categories are correct, and the report balances cleanly. So why does it fall apart for real businesses?

The answer comes down to the difference between standard Xero accounts and custom accounts created by users.

Standard Xero Accounts: The Easy 85–90%

When you first set up Xero, it provides a default Chart of Accounts a pre-built list of account categories like Sales, Cost of Goods Sold, Bank Fees, and so on. These accounts have well-known properties: a consistent Account Type, a Reporting Code, and a Source Type that the system can reliably read.

For these accounts, auto-mapping works extremely well. The system can confidently say: “This is a REVENUE account with Source Type ACCRECPAYMENT it belongs in Operating Cash Inflows.” No ambiguity, no guessing.

This covers the majority of transactions for most businesses roughly 85 to 90 percent of the chart of accounts.

GOOD NEWS

For most clean Xero setups with minimal customisation, auto-mapping alone will produce a highly accurate cash flow report with very little manual effort needed.

Custom User Accounts The Remaining 10–15%

Here is where it gets tricky. Real businesses rarely stick to the default chart of accounts.

Over time, their bookkeeper or accountant creates custom accounts tailored to their specific needs. These might look like:

“Donations” : could mean income, expense, or an asset purchase
“Owner Drawings” : could be equity withdrawal or a financing movement
“Special Income” : unclear without knowing what the business does
“One-Time Expense” : no standard classification exists for this
“Director Loan” : could be liability repayment or financing inflow

These accounts have no standard Reporting Code. Their Account Type might be generic. And most importantly, the name alone tells us nothing definitive about where they belong in a cash flow report.

This is the 10 to 15 percent of accounts that causes 90 percent of the mismatches.

Chapter 10: How Other Tools Handle This (Industry Practice)

We are not the first to face this challenge. Established financial reporting tools that connect to Xero such as Spotlight Reporting, Reach Reporting, and SIFT Analytics have all developed a well-proven approach to handle this exact problem.

Rather than trying to auto-classify everything and hoping for the best, these tools introduce a structured mapping review step between data sync and report generation. Here is how their workflow looks:

Step	Action	What Happens
1	Connect & Sync	The tool connects to Xero and pulls all account and transaction data.
2	Auto-Map	The system automatically classifies all standard accounts it can confidently identify.
3	Show Mapping Screen	A review screen displays: mapped accounts in their correct buckets, and unmapped accounts in a separate list.
4	Admin Fixes the Rest	The admin or finance user drags and drops (or selects from a dropdown) to assign the remaining unmapped accounts – typically 5 to 10 minutes of work.
5	Generate Report	The final cash flow report is generated using the combination of auto-mapped rules and the saved manual overrides.

The most important detail in this workflow is Step 4. The manual mapping is a one-time effort per organisation.

Once an admin has told the system that “Owner Drawings” belongs in Financing Activities, that mapping is saved and reused automatically every month going forward. No repeated work. No developer involvement required.

KEY PRINCIPLE

Auto-classify as much as possible. Give the admin a simple override tool for the rest. Save it once. Reuse it every month. This is the industry-standard approach and it works.

Chapter 11: The Two-Layer Mapping Model

Drawing from industry best practice, the recommended solution is a two-layer mapping model.

Think of it as a smart system with a human safety net one that handles the obvious cases automatically, and hands off the edge cases to the people who actually know the business.

Layer 1 – Auto-Mapping (The Smart System)

The first layer handles everything the system can classify with confidence. This is rule-based logic that looks at three stable properties of each account:

Account Type for example, REVENUE, EXPENSE, ASSET, LIABILITY, EQUITY
Source Type the type of transaction, such as CASHPAID, ACCRECPAYMENT, CASHREC
Reporting Code / Reporting Code Name Xero’s own classification codes like ASS.NCA.FIX.PLA for fixed assets

Using these three signals together, the system can confidently classify roughly 85 to 90 percent of all accounts into the correct cash flow section. For businesses with a clean, standard chart of accounts, this accuracy can be even higher.

Layer 2 – Manual Mapping (The Human Safety Net)

For the accounts that remain unclassified or are flagged as uncertain, the second layer kicks in. This is a simple, user-friendly interface where an admin or finance user can:

See a list of all unmapped or uncertain accounts in one place
Assign each account to the correct cash flow bucket Operating, Investing, or Financing using a dropdown or drag-and-drop
Save the mapping once it is stored and applied automatically every subsequent month
Override any incorrectly auto-mapped account if needed

The expected time investment for this manual step is just 5 to 10 minutes per organisation, done once during initial setup.

	Layer 1: Auto-Mapping	Layer 2: Manual Mapping
Who does it?	The system automatically	Admin or finance user
Coverage	~85–90% of accounts	Remaining 10–15%
Time required	Instant, runs on sync	5–10 minutes, one-time per org
Basis	Account Type, Source Type, Reporting Code	Human judgement and business context
Frequency	Every sync, automatically	Once per org, then reused monthly

Chapter 12: The New End-to-End Workflow

With the two-layer model in place, the overall workflow for generating a cash flow report changes slightly compared to before.

The key difference is the mandatory mapping review step that now sits between data sync and report generation.

This step is what transforms the system from one that guesses and gets it partially wrong, to one that is accurate, explainable, and consistent month after month.

The New Workflow Step by Step

Connect Xero: The user connects their Xero account to your reporting platform.
Sync COA and Transactions: The system pulls the full chart of accounts and all cash journal entries from Xero.
Run Auto-Mapping: Layer 1 immediately classifies all accounts it can identify with confidence, using Account Type, Source Type, and Reporting Code rules.
Show Mapping Review Screen: A clear review screen appears, showing: all auto-mapped accounts under their correct cash flow lines, and all unmapped or uncertain accounts in a separate list below.
Admin Assigns the Remaining Accounts: The admin reviews the unmapped list and assigns each account to the correct cash flow section. This is a one-time effort, taking roughly 5 to 10 minutes.
Mapping is Saved: The completed mapping is stored against the organisation and will be applied automatically in all future monthly reports.
Cash Flow Report is Generated: The final report is built using auto-mapping rules plus all saved manual overrides, producing an accurate, balanced, and consistent output.

IMPORTANT CHANGE

Previously, the report was generated immediately after sync. Now, there is one extra step the Mapping Review. This is not a burden; it is the feature that makes the report trustworthy.

Chapter 13: Where Should the Mapping Live?

A practical question came up during discussions: who builds the mapping screen, and where is the mapping data stored? Two options were explored.

Option 1 Mapping UI in the Middleware (the middleware provider Side)

In this approach, the middleware provider builds the mapping screen inside the middleware or admin portal.

The mapping data is stored in the middleware database. your reporting platform simply consumes the already-categorised cash flow data via an API they never see the raw unmapped accounts.

Simpler for your reporting platform to integrate they just get a clean, categorised result
Mapping is centrally managed by the middleware provider or a shared admin
Less flexibility for end-customers to manage their own mapping

Option 2 – Mapping UI in your reporting platform (Recommended)

In this approach, the middleware provider provides the intelligence and the APIs, but your reporting platform builds the mapping screen inside their own application. This gives the end-customer a native, seamless experience.

The middleware provider’s role in this model:

Provide an API that returns the list of unmapped accounts for a given organisation
Provide an API that accepts mapping overrides submitted by the user
Apply the saved mapping automatically during every report generation run

Your reporting platform’s role in this model:

Build a simple, clean mapping screen in their application
Allow the end-customer or admin to assign accounts during onboarding
Submit the mapping back to the middleware provider’s API for storage and application

Factor	Option 1: Middleware UI	Option 2: your reporting platform UI (Recommended)
End-user experience	Admin portal, less native feel	Seamless inside your reporting platform app
Who builds the UI?	the middleware provider / middleware team	your reporting platform team
Where is mapping stored?	Middleware database	your reporting platform, synced to middleware
Customer control	Limited	Full – admin can update mapping anytime
Recommended?	No	Yes

Chapter 14: Success Criteria & Open Questions

With the two-layer model implemented correctly, the system should deliver on two levels of success primary outcomes for the end report, and secondary outcomes for the operational experience.

Primary Success Criteria

These are the non-negotiable outcomes that define whether the solution has worked:

The cash flow report must reconcile and balance as closely as possible to Xero’s own bank and cash balances
Even for accounts where categorisation involves some judgement, the output must be explainable the admin must be able to point to why each line appears where it does
The report must be consistent month-on-month the same account must always appear in the same section, with no unexplained jumps or reclassifications between months

Secondary Success Criteria

These outcomes determine how smooth the ongoing experience is:

An admin can fix any remaining classification gaps themselves, no dependency on the development team
The mapping effort stays small and is a one-time task per organisation, not a recurring monthly burden

Open Questions for your reporting platform Team

Two important decisions still need to be made before implementation begins:

1. Who Owns the Mapping?

Should mapping changes be restricted to your reporting platform internal admin team only? Or should end-customers (the business owners or their accountants) also be able to adjust mappings themselves? And should every mapping change be recorded in an audit trail showing who changed what and when?

2. Where Should Mapping Be Stored?

Should the mapping data be stored in the middleware database and pushed out to your reporting platform via API? Or should it be stored inside your reporting platform system and sent to the middleware whenever the report is generated? Each approach has implications for data ownership, sync reliability, and the user experience.

RECOMMENDATION

Resolve these two questions before starting development. They affect database design, API contracts, and the security model. Getting alignment early avoids costly rework later.