Ask most property-management finance teams how they collect vendor banking details and the answer is some version of: a form gets emailed, a vendor fills it in, it comes back as a scan, and someone in AP keys the routing and account numbers into the ERP by hand.
Every step of that flow is a problem. It's slow, it's manually re-keyed (so it's error-prone), and — the part that should worry a public entity most — bank details are travelling around in email attachments, which is exactly where payment-redirection fraud lives.
The better pattern is to capture ACH details once, at the source, from the vendor themselves, through a supplier self-service portal — and then push that data into Yardi Voyager through a controlled, scheduled export rather than a keyboard.
Why the supplier should enter their own bank details
The vendor knows their own routing and account numbers better than anyone in your AP department does. Letting them enter the data directly removes the most common error source — transcription — and creates a clean audit trail of who provided the information and when.
A workable supplier portal flow looks like this:
- A vendor is invited by the housing authority (or property manager) to the supplier portal.
- The vendor completes sign-up, creating their own username and password.
- Once approved, the vendor signs in and navigates to a dedicated Payment Details page — not buried three screens deep, but a clear item in the side navigation.
- They enter their ACH details and save.
Putting ACH capture into the sign-up workflow itself helps too: when a newly invited supplier creates their account, the bank-detail fields are right there, so the data arrives complete instead of trickling in later. Automated follow-up reminders catch the vendors who skip it.
The controls a public entity needs
For a housing authority or any organization spending public funds, "collect the bank details" is only half the requirement. The other half is governance, and it's where a generic form falls short. The questions worth settling before you build:
- Who can see ACH data? A vendor's banking information shouldn't be visible to every internal user. Decide early whether ACH details are visible only inside the supplier portal, or also to specific internal roles — and if internal, which roles. Role-based visibility isn't a nice-to-have here; it's a control.
- How are changes handled? A bank-detail change should be a flagged, reviewable event — not a silent overwrite. This is the single most important defense against payment-redirection fraud.
- Where do the details actually live? Bank data should sit in your platform under access control, not scattered across an inbox.
Public entities also frequently need to handle adjacent payment scenarios — for example, garnishments against a vendor's payments. Capturing those alongside ACH details, in the same structured place, keeps the whole payment picture in one governed system rather than in side spreadsheets.
Getting the data into Yardi Voyager — without re-keying
Yardi Voyager ingests vendor and payment data through SFTP file import, typically as a formatted CSV that Voyager picks up and loads. That's the same mechanism property-management teams already use for invoice export and property / GL account import, so you're not introducing a new integration surface — you're reusing a proven one.
The export design that holds up in production has a few characteristics:
- A scheduled, automated export — a job runs on a set cadence, queries the captured ACH records, reformats them into the layout Yardi expects, and drops the file on the intermediary SFTP server for Voyager to collect. No human assembles the file.
- Format discipline. Voyager is particular about field layout and restricted characters. The export logic enforces the target format so the import doesn't reject rows.
- No disruption to the existing pipeline. Because it rides the same SFTP infrastructure already moving invoices and property data, adding ACH export doesn't change how anything else is delivered.
The result: a vendor enters their bank details once, in a controlled portal, and those details land in Yardi Voyager on a schedule — validated, formatted, and never re-typed.
Where EZ Cloud fits
This is exactly the kind of property-management AP problem EZ Cloud was built to absorb. We provide the supplier self-service portal that captures ACH details (and garnishments) at the source with role-based visibility and change controls, and the scheduled SFTP export that delivers a correctly formatted CSV into Yardi Voyager — reusing the same import pipeline you already trust for invoices and property data.
A US housing authority runs this pattern in production today, which we've written up in our HACOV case study. The full picture of how we connect to Voyager — invoice import, payment export, multi-property GL coding, and ACH capture — lives on our Yardi integration page.
If your team is still collecting bank details by email and re-keying them into Voyager, the portal-plus-export pattern is the upgrade worth planning. It's faster, it's cleaner, and for an organization spending public money, it's a meaningfully stronger control posture.