> For the complete documentation index, see [llms.txt](https://docs.coupler.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.coupler.io/sources/category/finance-and-accounting/brex/best-practices.md). # Best Practices ## Recommended setup


Use a dedicated read-only API token	Generate a Brex API token scoped to read-only access for each resource you need. Avoid reusing tokens across tools — if a token is compromised, a dedicated one limits exposure.
Join Transactions with Users and Departments	Transactions alone don't tell the full story. Use Coupler.io's Join transformation to enrich transaction data with user names and department names for meaningful cost center reporting.
Append data from multiple Brex accounts	If your organization runs more than one Brex account, create a separate source for each API key and use the Append transformation to consolidate everything into one destination table.
Start with a focused date range	For Transactions and Expenses, begin with the current quarter rather than pulling all historical data at once. This keeps your first run fast and lets you validate the data before expanding the range.

## Data refresh and scheduling


Refresh Transactions daily	Pending transactions settle over time and amounts can change. A daily refresh ensures your reports reflect settled values and capture new spend promptly.
Refresh Budgets at least weekly	Budget remaining amounts are point-in-time snapshots. For active budget periods, weekly refreshes keep your budget vs. actual reports accurate enough for most finance reviews.
Sync Users and Departments less frequently	These entities change rarely — new hires, offboarding, or restructuring. A weekly or monthly refresh is usually sufficient, saving API calls for the entities that matter more.

## Performance optimization


Filter by status in your destination	Rather than filtering at the source, pull all transaction statuses and filter in your spreadsheet or BI tool. This gives you flexibility to switch between pending and settled views without re-running the data flow.
Use Aggregate for summary reporting	If you're building a high-level spend dashboard, use Coupler.io's Aggregate transformation to pre-summarize spend by department, category, or month — reducing the data volume hitting your destination.

## Common pitfalls {% hint style="danger" %} Don't build reports on pending transactions. Pending amounts are estimates and will change once the transaction settles. Always flag status in your reports and base financial conclusions on settled data only. {% endhint %} {% columns %} {% column %} **Do** * Use separate API tokens for Coupler.io and other integrations * Join Transactions with Departments for cost center attribution * Validate your first run before scheduling * Pull a short date range first to confirm data looks correct {% endcolumn %} {% column %} **Don't** * Use a single broad-scope admin token across all tools * Rely on Budget remaining amounts without checking the last sync time * Set the start date to a year ago on your first run without testing a shorter range first * Treat draft expenses as final — they may be rejected or edited {% endcolumn %} {% endcolumns %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.coupler.io/sources/category/finance-and-accounting/brex/best-practices.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.