Acquiring banks, ISOs and merchant portfolios depend on TSYS to process card payments. TSYS handles authorization, and clearing, and it reports on the activity it processes. But confirming that the processed activity matches what lands in your bank accounts and general ledger is a separate job. For many finance teams, that job still runs on manual checks, copy-pasted totals and spreadsheets.
Simetrik is built for that gap. TSYS processes the transactions. Simetrik helps TSYS clients verify that the data TSYS produces matches their deposits and their books, down to the transaction.
This guide explains why TSYS acquiring data can be difficult to work with and what the manual process looks like today. It also covers how Simetrik turns raw TSYS output into automated, auditable financial checks.
The challenge of managing TSYS acquiring data
On the acquiring side, TSYS processes card transactions for merchants on behalf of acquiring banks and ISOs. It routes authorizations, submits transactions to the card networks for clearing, and calculates interchange and processing fees. It also funds merchants through settlement deposits.
Every step leaves a data trail. Finance teams have to reconcile several things:
- authorizations and cleared transactions, which often land on different days;
- settlement batches and the net deposits that reach the bank;
- interchange, network assessments and processing fees, which are usually netted out of the deposit instead of shown line by line;
- chargebacks, reversals and adjustments, which can change settled amounts after the fact.
None of this is a flaw in TSYS. It’s how card acquiring works. But it creates exactly the kind of multi-source, transaction-level matching that manual processes struggle with as merchant volume grows.
The manual reality: from green screens to unstructured data
Green screens as the daily system of record
Many TSYS environments still rely on legacy host-based systems accessed through 3270-style terminal screens, informally called “green screens.” Analysts log in, navigate across multiple screens, and copy-paste values into daily balancing spreadsheets. Each screen has its own format and its own tables.
Several of the reports teams depend on are only available inside these screens and don’t feed into any BI tool. The screens also have no export function, so every number that reaches a spreadsheet is typed or pasted by hand.
This makes TSYS reconciliation a variability problem as much as a volume problem. The effort comes from how many formats a team has to pull together each day, not only from how many transactions there are.
Built to investigate, not to reconcile
Green screens are designed to look up a known exception, not to reconcile a full population of transactions. To query anything, you already need the right identifier: the STAN (system trace audit number), the merchant or the terminal.
When the day’s balance doesn’t match the bank statement, the screens offer no drill-down. The analyst has to work backward through several screens and into a spreadsheet to find the difference.
There’s also a recurring date mismatch. The processing date used for daily verification doesn’t always line up with the effective date the bank uses. That breaks the balance on a regular basis, even when nothing is actually wrong.
Face value numbers without the detail behind them
Much of what teams see in these views are bulked amounts. For example, a single $1,000,000 settlement figure is a face value number. It says how much moved, but not which transactions, fees and adjustments make up that total. Reconciling at this aggregate level (high-level totals with no transactional detail) leaves variances unexplained until someone investigates them manually.
Raw TSYS files are hard to read
The underlying data exists, but not in a usable form. TSYS delivers financial movement data as large, unstructured files made of dense character strings and code lines, without the readable columns a finance team would expect. Before anyone can calculate or match against this data, it has to be parsed and converted into structured tables.
What this costs finance teams
Every figure copied from a terminal screen adds validation work to each downstream journal entry. The process depends on the few people who know how to navigate the screens. And each manual step is another chance for an entry error that ends up in the books. Transaction-level matching becomes too labor-intensive to run every day, so most teams settle for reconciling totals and investigating differences after the close.
How Simetrik transforms TSYS data into verified, transaction-level detail
Simetrik is an AI-native financial control platform. Its core is transaction-level reconciliation. For TSYS clients, Simetrik works from the raw data files TSYS delivers rather than from green screens. It turns those files into a structured, rule-based reconciliation workflow.
Data parsing: turning raw TSYS output into readable tables
Simetrik ingests TSYS files through compatible methods. It parses the unstructured strings into clean, tabular data with defined columns, dates and amounts. AI can suggest how to interpret non-standard file layouts, and the team reviews a preview before the configuration is applied.
The value is that the team no longer has to rebuild the day’s numbers by hand from screen after screen.
Financial reconciliation: unpacking bulked amounts
With the data in structured form, Simetrik can compare three things: the transaction-level detail behind each settlement, the net deposit in the bank statement, and the entries in the ledger. Matching rules can relate one deposit to the many transactions it contains. Tolerances and timing rules can account for the gap between processing date and effective date.
A face value number stops being a black box. Records that match are separated from the ones that don’t, and each exception is traced to the rule that flagged it.
Automated enrichments: fees, adjustments and deductions
Simetrik applies configured calculations, transformations and enrichments to the parsed data. These cover interchange, processing fees, authorization fees, adjustments and deductions. This makes it possible to rebuild the path from gross transaction volume to the net amount deposited, and to see where the two diverge.
Chargebacks, reversals and adjustments can be brought in as their own data sources. They’re then matched back to the original transaction and settlement. A late change shows up as a specific exception to investigate instead of an unexplained variance in a period the team thought was closed.
Auditable by design
AI helps teams configure and adapt matching logic when file layouts, merchant portfolios or volumes change, including through natural-language setup. The matching itself runs on a deterministic core. With the same data and the same rules, Simetrik produces the same result. Every match, exception and manual action can be traced back to a visible rule and a named reviewer.
Business impact: automated tracking of financial movements
For TSYS clients, the shift is from checking totals to verifying transactions:
- Less manual effort. Analysts spend less time copying numbers across green screens and rebuilding daily balancing templates, and more time investigating the exceptions that matter.
- Lower operational risk. Fewer hand-keyed figures mean fewer entry errors reaching the books and less dependence on the few people who know the screens.
- Clarity on money movements. Bulked amounts are unpacked into the transactions, fees and adjustments behind them, so the team can explain the gap between processed volume and net deposits.
- Cleaner inputs for accounting. Verified, transaction-level data gives downstream journal entries a traceable source, which reduces the extra validation each entry needs today.
- Better control of financial discrepancies. Teams can identify incorrectly charged fees, unexpected charges, and chargebacks that are missing, mismanaged, or incorrectly accounted for, making it easier to investigate and recover discrepancies.
See how Simetrik reconciles your TSYS acquiring data, from raw file to ledger. Book a demo.
Frequently asked questions
Is TSYS a reconciliation platform?
No. TSYS is a payment processing platform. On the acquiring side, it authorizes, clears and settles card transactions for merchants and reports on that activity. It doesn’t reconcile that activity against a client’s bank accounts or internal ledger. That verification is the job Simetrik is built for.
Why is reconciling TSYS acquiring activity harder than it sounds?
A single merchant portfolio on TSYS generates several parallel data streams, and they rarely arrive at the same time or in the same file. These include authorizations, cleared transactions, settlement batches, netted fees, chargebacks and adjustments. As the number of merchants, entities or currencies grows, so does the number of streams to align. That makes manual tracking harder to sustain.
What is the typical process for checking financial movements in TSYS?
Many finance teams check financial movements by logging into legacy green screens and reviewing bulk totals. They then copy those face value numbers into daily balancing spreadsheets and compare them against bank statements and ledger entries. Because this depends on manual copy-paste, matching usually happens at the aggregate level rather than per transaction. With automated ingestion, the raw TSYS data is parsed and matched at the transaction level instead.
Why are TSYS data files so difficult to parse for financial reconciliation?
TSYS delivers financial movement data as unstructured files made of dense character strings and code lines, with no readable column structure. Before any calculation or matching can happen, those strings have to be parsed into tabular data with defined fields such as dates, amounts, merchant identifiers and fee types. Simetrik handles that parsing as the first step of the reconciliation workflow.
How does Simetrik handle fee calculations, adjustments and bulked amounts from TSYS?
Simetrik ingests the bulked amounts (face value numbers) along with the underlying TSYS data and parses the line-item detail. It then applies configured fee calculations, adjustments and deductions. This lets teams rebuild how gross volume becomes the net deposit, and match each component against the bank and the ledger. Differences are flagged as exceptions for review.
Why do many organizations use processor portals?
Processor portals and reporting interfaces give teams operational views of processing activity. They’re used to monitor authorizations, pull daily settlement reports and handle administrative tasks such as chargeback responses. They’re built to report on processor output, not to run transaction-level financial controls. Finance teams still have to extract that data and reconcile it against their bank deposits and accounting records.
Which legacy tools, such as green screens, create bottlenecks in TSYS reconciliation?
Many acquiring banks and ISOs still rely on 3270 terminal green screens to verify daily balancing totals. These screens have no export function, so analysts copy and paste figures across multiple screens by hand. This creates dependence on a few key people and increases the risk of data entry errors. It also adds audit risk to every downstream accounting entry built from those numbers.
How does Simetrik work with TSYS data?
Simetrik works with the files and reports TSYS delivers to its clients, not with the green screens. It ingests settlement, clearing, fee and adjustment data alongside bank statements and ledger data, parses it into structured tables and applies configured matching rules. Matched records are separated from exceptions that need investigation.
Do TSYS clients still need a separate reconciliation platform?
Usually, yes. TSYS processes the transactions, but it doesn’t check that what it processed matches what settled into the bank and what’s recorded in the ledger. For clients with growing merchant volume, multiple data streams or manual green-screen processes, that independent check is where a reconciliation platform like Simetrik fits.
