Financial Data Interface Configuration and ERP Integration
The Financial Data Interface, commonly shortened to FDI, is the structured export mechanism that moves card program transaction, payment, and account data out of US Bank Access Online and into an organization's accounting or enterprise resource planning system. This page explains how FDI is configured within US Bank Access Online, what the output files contain, how those files map to a general ledger, and how the resulting data lands cleanly inside common ERP platforms. It is written for program administrators, treasury analysts, and systems integrators who are responsible for automating the flow of spend data rather than keying it in by hand.
In US Bank Access Online, FDI sits between the transaction data that accumulates during a billing cycle and the financial records your organization keeps of record. A correctly built FDI configuration in US Bank Access Online turns thousands of individual purchasing card, travel card, and one-card transactions into a single predictable file that your ERP can consume on a schedule, with account codes already assigned, tax fields already populated, and cardholder attributes already resolved. When it is set up well, month-end close shrinks and manual coding largely disappears.
What the Financial Data Interface is
FDI is a reporting and extract facility within US Bank Access Online that produces a defined, repeatable data file describing your card program activity. Rather than being a single fixed report, it is a template you build in US Bank Access Online. You choose which data elements appear, in what order, under what field names, and in what output structure. Once that template is approved and activated, US Bank Access Online generates a file against it whenever the schedule triggers, so the same layout arrives every cycle without an administrator having to rebuild it.
The purpose is integration, not human reading. Where the standard on-screen reports in US Bank Access Online are meant to be viewed and interpreted by a person, an FDI file is meant to be parsed by a machine. That distinction shapes every decision you make: field widths must be stable, delimiters must be consistent, dates must follow a single format, and codes must match exactly what the receiving system expects. An FDI configuration is essentially a contract between US Bank Access Online and your ERP, and both sides have to agree on the terms.
The data FDI can carry
A typical FDI extract from US Bank Access Online carries transaction-level records enriched with account and hierarchy context. The most common elements include the posting and transaction dates, the transaction amount and currency, the merchant name and merchant category code, the masked account number, the cardholder or accountholder name, and any accounting code assigned to the transaction. Where enhanced data is available, US Bank Access Online can also include line-item detail, sales tax amounts, and Level II or Level III fields supplied by the merchant.
Because those enriched fields depend on what merchants transmit, an FDI configuration in US Bank Access Online should be built to handle records that arrive without them. A well-designed file defines a default or blank behavior for optional fields so the ERP import does not fail when a merchant sends only a total. Deciding early how US Bank Access Online should represent missing tax or line-item data saves a great deal of troubleshooting later.
File formats and record layouts
FDI output from US Bank Access Online is generally produced in a flat structured form. The two families you will encounter are delimited files, where each field is separated by a character such as a comma, pipe, or tab, and fixed-width files, where each field occupies a defined number of character positions regardless of the value it holds. Your ERP dictates which one you build in US Bank Access Online. Delimited files are easier to read and forgiving of length changes; fixed-width files are stricter but map cleanly to legacy mainframe and older ERP importers that expect data at exact column offsets.
When you build a fixed-width layout in US Bank Access Online, the discipline is in the record specification. Every field needs a start position, a length, a justification, and a fill character. Numeric fields are usually right-justified and zero-filled; text fields are usually left-justified and space-filled. If your ERP import routine reads amounts as implied-decimal integers, the FDI configuration must strip the decimal point and pad accordingly. Getting these details exactly right is the single most common source of failed first-run imports, so treat the layout document as authoritative and test against it byte by byte.
| Field | Type | Length | Format note |
|---|---|---|---|
| POST_DATE | Date | 8 | YYYYMMDD |
| TXN_AMOUNT | Numeric | 13 | Right-justified, zero-fill, implied 2 dp |
| ACCOUNT_NBR | Text | 19 | Masked, left-justified |
| MCC | Numeric | 4 | Merchant category code |
| GL_CODE | Text | 24 | Mapped account string |
The layout above is illustrative of how a US Bank Access Online extract is described rather than a fixed standard. Your own specification document, agreed with your implementation contact, is the version that governs. Treat character encoding as part of that specification too: confirm whether your ERP expects ASCII or UTF-8, and decide how US Bank Access Online should handle accented merchant names and other non-ASCII characters before the first production file runs.
Account and general ledger mapping
Mapping is where an FDI configuration earns its value. On its own, a transaction record from US Bank Access Online knows the merchant, the amount, and the account, but it does not natively know how your chart of accounts is structured. The mapping layer translates card program attributes into the account strings, cost centers, and expense categories your ERP recognizes. This is what lets a coffee-shop charge on a specific cardholder's account arrive in your ledger already posted to the right department and the right expense line.
There are two broad approaches, and most programs use both. The first is default coding, where a cardholder or account carries a standing accounting code that US Bank Access Online applies to every transaction unless overridden. The second is transaction-level coding, where a reviewer assigns or corrects the code before the cycle closes, and the FDI extract from US Bank Access Online captures whatever the final approved value is. A robust configuration in US Bank Access Online should decide which value wins when both exist, so the exported code is never ambiguous.
Using the account hierarchy
Programs are organized in US Bank Access Online as a hierarchy of processing points, divisions, and accounts. FDI can carry the hierarchy identifiers alongside each transaction, which is enormously useful for ERP systems that post to entities or business units. If your organization runs multiple legal entities on one card program, mapping the hierarchy node in US Bank Access Online to the ERP company code lets a single FDI file feed several sets of books without splitting the extract manually.
Delivery, scheduling, and security
Once a file is built, US Bank Access Online has to deliver it somewhere your systems can reach. The most common channel for automated integration is secure file transfer, where US Bank Access Online places the file on an agreed endpoint and your ERP or middleware retrieves it. Smaller programs sometimes rely on manual download from within the US Bank Access Online portal, then load the file by hand. Automated delivery removes the human step and makes the schedule dependable, which matters most for organizations that close on a strict calendar.
Scheduling is tied to the billing cycle. A file can run at cycle close, on a fixed calendar day, or on demand. When you configure the cadence in US Bank Access Online, align it with your ERP import window so the file is waiting when the accounting team is ready and not so early that late-posting transactions are missed. Many programs run a full-cycle extract from US Bank Access Online plus a supplemental run to catch transactions that posted after the initial file was generated.
Security controls apply throughout. Files carrying account and spend data should move over encrypted channels, and access to the FDI configuration itself is an entitlement that only administrators should hold. Because the extract can expose sensitive program information, US Bank Access Online treats changes to the interface as auditable events. Restrict who can edit a layout in US Bank Access Online, review delivery credentials periodically, and confirm that masked account numbers in the output meet your data-handling policy before you distribute files internally.
Integrating with ERP and accounting systems
An FDI file from US Bank Access Online is agnostic about which ERP consumes it, which is the point. Because the format is a plain structured file, it can feed SAP, Oracle, Microsoft Dynamics, Workday, NetSuite, or a homegrown ledger equally well, provided the layout matches what the target import expects. The integration work is not in US Bank Access Online alone; it is in the agreement between the file US Bank Access Online produces and the interface the ERP presents.
Most ERP platforms accept card data through a journal import, an expense feed, or an accounts payable voucher load. Your choice determines what fields the FDI file from US Bank Access Online must include. A journal import typically needs balanced debit and credit lines with account strings, so your mapping in US Bank Access Online has to produce both the expense account and the offsetting clearing account. An expense feed may need employee identifiers to attach spend to the right person. Knowing the target interface first, then building the FDI layout backward from it, avoids costly rework.
Middleware and transformation
Some organizations transform the FDI file in a middleware layer before the ERP sees it. This is a legitimate pattern and often the cleanest one. Rather than forcing US Bank Access Online to produce an exact ERP-proprietary format, you have US Bank Access Online produce a stable, well-documented file, then let an integration tool reshape and enrich it. This decouples the two systems so an ERP upgrade does not require a change to the FDI configuration, and a change in US Bank Access Online can be absorbed in the middleware without touching the ledger.
Whether you transform or load directly, keep the raw file that US Bank Access Online produced as the source of truth. If a posting is ever questioned, being able to point back to the exact bytes US Bank Access Online delivered, before any transformation, resolves disputes quickly and supports your audit position.
Integration methods compared
Not every program needs the same level of automation. The table below compares the main ways organizations move data out of US Bank Access Online, from manual export to fully scheduled FDI delivery, so you can match the effort to your volume and close discipline.
| Method | Setup effort | Automation | Best for |
|---|---|---|---|
| Standard report export | Low | Manual | Small programs, occasional loads |
| FDI manual download | Medium | Partial | Fixed layout, human trigger |
| FDI scheduled delivery | High | Full | High volume, strict close |
| FDI via middleware | High | Full + transform | Multi-entity, complex ERP |
For most mid-size and large programs, scheduled FDI delivery from US Bank Access Online is the sensible target. It pays back the higher setup effort within a few cycles by removing manual coding and download work, and it makes the close date predictable. The manual report export in US Bank Access Online remains a fine fallback for a new program that has not yet earned the volume to justify a full FDI build.
How to get started
Building an FDI configuration is a project, not a setting you flip. The sequence below reflects the order most organizations follow when connecting US Bank Access Online to a general ledger.
-
STEP 01
Confirm the target. Document the exact import format your ERP expects, including field names, lengths, date formats, and whether it wants balanced journal lines. This target specification drives every later decision in US Bank Access Online.
-
STEP 02
Build the mapping table. Translate cardholder accounts, hierarchy nodes, and merchant categories into your chart of accounts, and decide how default coding and reviewer coding interact so US Bank Access Online exports one unambiguous code per transaction.
-
STEP 03
Design the layout. Define each field, its format, and its position, then have your implementation contact configure the extract template in US Bank Access Online to match the specification exactly.
-
STEP 04
Test with real data. Run a sample extract from US Bank Access Online, load it into a non-production ERP environment, and reconcile the totals line by line. Fix layout and mapping errors here, before anything posts to live books.
-
STEP 05
Activate the schedule. Set the delivery cadence and endpoint in US Bank Access Online, run the first production cycle under close supervision, and monitor the first several cycles until US Bank Access Online is delivering clean files without intervention.
Validation and reconciliation
A file that loads without an error is not the same as a file that is correct. The discipline that keeps an FDI integration trustworthy is reconciliation: proving that what US Bank Access Online exported equals what your ERP posted. The standard control is a control total, where the sum of transaction amounts and the record count in the file from US Bank Access Online are compared to the sum and count that landed in the ledger. If they match, the load is clean; if they do not, you find the gap before close.
Watch for the common failure modes. Duplicate loads happen when a file is imported twice; a sequence or file identifier in the extract from US Bank Access Online lets you detect and reject repeats. Dropped records happen when the ERP rejects lines it cannot map, so any transaction whose code did not resolve should route to a suspense account rather than vanish. Sign errors happen when credits and refunds are not represented the way the ERP expects, which is why testing US Bank Access Online with a cycle that contains returns is worth the extra effort.
The example ledger below shows how exported records appear once posted, with authorization status carried through from US Bank Access Online so reviewers can see at a glance which lines were approved and which are still pending.
| Post date | Merchant | GL code | Amount | Status |
|---|---|---|---|---|
| 20240603 | OFFICE SUPPLY CO | 6410-100-OPS | 412.55 | Approved |
| 20240603 | AIRLINE 0114 | 7220-300-TRV | 638.00 | Pending |
| 20240604 | CLOUD SVCS INC | 6510-200-ITX | 1,240.00 | Approved |
| 20240604 | FUEL STATION 88 | 7230-300-TRV | 74.20 | Approved |
Treat reconciliation as a permanent control, not a launch task. Even after US Bank Access Online has delivered clean files for months, a chart of accounts change, a new merchant category, or a fresh cardholder without a default code can introduce a gap. A short monthly reconciliation of the US Bank Access Online extract against posted totals is cheap insurance against a costly restatement.
Frequently asked questions
Is FDI the same as a standard report from Access Online?
No. Standard reports in US Bank Access Online are built for people to read on screen or in a spreadsheet. FDI is a machine-readable extract from US Bank Access Online built to a fixed specification so an ERP can import it automatically. They draw on the same underlying data but serve different purposes.
Which ERP systems can consume an FDI file?
Because the FDI output from US Bank Access Online is a plain structured file, any ERP or accounting system that can import a delimited or fixed-width file can consume it, including major platforms and custom ledgers. The work is matching the US Bank Access Online layout to what the target import expects.
Who is allowed to configure or change the interface?
Editing an FDI layout, mapping table, or delivery schedule is an administrator-level entitlement in US Bank Access Online. Because a change affects how every future transaction posts, access to US Bank Access Online should be limited and changes should be recorded for audit.
How often can files be delivered?
Delivery cadence is configurable and usually tied to the billing cycle. US Bank Access Online can produce a file at cycle close, on a calendar day, or on demand, and many programs add a supplemental run in US Bank Access Online to capture late-posting transactions.
What happens when a transaction has no accounting code?
Decide this in the configuration. Best practice is for US Bank Access Online to apply a default code or a designated placeholder so the record still exports and the ERP routes it to a suspense account for review, rather than dropping the line silently.
Does the file include full card numbers?
Account numbers in an FDI extract from US Bank Access Online are typically masked to protect sensitive data. Confirm the masking behavior in your layout against your organization's data-handling policy before distributing files, and always move them over encrypted channels.
How do refunds and credits appear?
Credits and refunds are represented according to the sign convention agreed in your layout. Test a cycle that contains returns so you can confirm that US Bank Access Online represents them in the way your ERP posts negatives, avoiding sign errors at load time.