A few months ago, one of our clients — a mid-sized financial services firm — came to us with a problem that sounded mundane on the surface but was quietly bleeding time and money. Every week, their ops team was manually copying data from Excel spreadsheets into a bank portal. Row by row. Field by field. Copy, paste, click, repeat. For hours.
When they told me the process took roughly 12 to 15 hours per week across two staff members, I knew immediately: this wasn't just a workflow problem. It was a solvable automation problem. And solving it became one of the most satisfying projects I've worked on at Helion 360.
Here's how we did it — and what you should know if you're facing the same challenge.
Why Manual Excel-to-Portal Uploads Break Down at Scale
The instinct to use Excel is completely understandable. It's flexible, familiar, and powerful for data manipulation. The problem isn't Excel — it's the last mile: getting that data into a bank or financial portal that doesn't have a native import button, or whose import function is buried, limited, or unreliable.
In this client's case, the bank portal accepted data entry only through a web-based form interface. There was no official API, no bulk upload CSV feature, and no support documentation that addressed automation. Their options seemed to be: keep doing it manually, or find another way.
We found another way.
Mapping the Workflow Before Writing a Single Line of Code
Before touching any automation tooling, I spent time sitting with the ops team to map exactly what the manual process looked like. This step is non-negotiable. Automation that mirrors a broken process just breaks faster.
Here's what we documented:
- The source Excel file structure — column names, data types, validation rules, and the frequency of updates
- The target portal's form fields — which fields were required, which had dropdowns, which had character limits
- The authentication flow — how staff logged in, whether sessions timed out, and whether MFA was involved
- Edge cases — what happened when a row had missing data, a duplicate entry, or a value that didn't match the portal's expected format
This discovery phase took about two days. It saved us from at least two weeks of debugging later.
The Technical Stack We Used
Because the bank portal had no API, we went with a browser automation approach using Python with Selenium WebDriver. For the Excel parsing side, we used openpyxl, which handles .xlsx files cleanly and gives you fine-grained control over cell reading and validation.
Here's the core architecture we built:
- Excel Parser Module: Reads the source spreadsheet, validates each row against a schema we defined (required fields, data type checks, format rules), and flags any rows that don't pass before the upload even begins.
- Portal Authentication Handler: Manages login, handles session persistence, and gracefully deals with session timeouts by re-authenticating mid-run if needed.
- Form Fill Engine: Iterates through validated rows and maps each cell value to the corresponding portal field. Dropdowns are handled by matching text values; date fields are reformatted to match the portal's expected input format.
- Error Logging and Reporting: Any row that fails to upload — due to a portal error, a timeout, or a validation mismatch — is logged with a reason code and exported to a separate Excel file for manual review.
- Run Summary Email: At the end of each automated run, the system sends a plain-text summary email showing how many rows were processed, how many succeeded, and how many need attention.
Handling the Hard Parts
The easy parts of this build are obvious. The hard parts are what most tutorials skip over.
Dynamic Page Elements
The bank portal used JavaScript-rendered forms, which meant some fields didn't exist in the DOM until a previous field was filled in. We had to build in explicit waits using Selenium's WebDriverWait and expected_conditions rather than relying on fixed sleep timers. This made the script significantly more stable across different network conditions.
MFA and Session Management
The portal required two-factor authentication on initial login. We handled this by building a semi-automated flow: the script pauses at the MFA step, prompts the operator to complete the authentication manually, then resumes once the session is established. Not fully hands-off, but it only added about 30 seconds to the process and kept security intact.
Data Validation Before Upload
One of the best decisions we made was front-loading validation. Before the script touches the portal at all, it runs every row through a validation pass and produces a pre-flight report. This meant the team could fix data issues in Excel before any upload attempt — dramatically reducing failed rows during live runs.
The Results After 30 Days
After a two-week build and a one-week testing period, we handed the automation off to the client's team with documentation and a simple run script they could trigger with a double-click.
The outcomes after the first 30 days of live operation:
- Weekly upload time dropped from 12-15 hours to under 45 minutes (including the pre-flight review)
- Error rate on uploaded records dropped from roughly 8% to under 1%
- The team reclaimed approximately 50+ staff hours per month — hours that went back into higher-value work
- The client reported a measurable reduction in end-of-week stress for the ops team
What This Approach Works For — and Where It Has Limits
Browser automation for portal integration is a pragmatic solution when a proper API isn't available. But it's important to be honest about its constraints. Portal UI changes can break scripts — a renamed field, a restructured form, or a portal migration can require script updates. We built in a monitoring step where the client runs a quick smoke test after any portal updates and flags us if something breaks.
This approach works well when: the portal is stable and infrequently redesigned, the data volume is moderate (hundreds to low thousands of rows per run), and the organisation has someone who can flag issues and coordinate fixes. It's less suitable for very high-volume, real-time, or mission-critical workflows where a proper API integration is worth negotiating with the bank directly.
Key Takeaways for Anyone Starting This Process
- Always map the manual workflow before automating — understand the edge cases first
- Front-load your data validation so problems surface before the upload runs
- Build error logging from day one, not as an afterthought
- Be realistic about maintenance — portal UIs change, and your script needs to be maintainable
- Document everything for the team who will operate it day-to-day
If your team is spending meaningful hours each week on repetitive data entry into a bank or financial portal, it's almost certainly automatable. The investment in getting it right upfront pays back fast — and keeps paying back every single week after that.