Business Process for One Time Payments
Hello everyone,
I am curious how other State, Local, or K-12 organizations are handling one-time payments to individuals or entities that are not registered suppliers.
A common example for us is property tax refunds issued to taxpayers who are not set up as suppliers. Our tax office does not use AR Billing for tax bills, as billing and collections are handled in a third-party tax system. We occasionally have similar scenarios for other types of refunds as well.
In our legacy system, a single voucher could be entered for multiple refunds and approved in batch. This does not translate well to Fusion for high-volume refund scenarios.
Currently, we are using an OTP (one-time payment) supplier, where departments attach a spreadsheet template to a single invoice to route the batch for approval. After approval, Finance loads the refunds using FBDI for one-time payment request. While this works, it is inefficient.
Because one-time payment requests must be created individually (even when loaded via FBDI), we have not found a clean way to replicate the legacy batch voucher process in Fusion.
We would be interested in hearing how others are handling this type of scenario. Are you using one-time payment requests, full supplier creation, or another approach? Have you found an efficient way to process higher-volume refunds in batch? Did you implement an integration from your tax / billing system to Fusion to handle these payments? How are you handling approvals?
Any insight into your business process, lessons learned, or things you would do differently would be greatly appreciated.
Miranda Stafford
Best Answer
-
Yamhill County has this exact issue. I recommend you email Tara Williams at Yamhill County. I think we have a good solution. She can tell you how we manage. williamst@yamhillcounty.gov
Answers
-
Thank you. I have sent her an email!
-
CPS has a similar issue. We need to pay a lot of parents that are not in Oracle as suppliers. We are planning on leveraging the one time payment FBDI spreadsheet process, but we would be interested in a different solution as well.
-
We utilize OIC to bring in one time payments automatically from each source system. We've set up the BPM workflow to auto approve based on the Invoice Source, as the payments have already been approved in their respective source systems.
-
@Steven Greenway thank you! The challenge we face is inconsistent address data from the source system. Is that an issue for you as well? If so, any suggestions on how to address it? For example, our source system stores address in one text box. The Street, City, State and Zip are not always consistently stored which makes creating an interface for the FBDI challenging.
-
We've faced similar challenges and haven't come up with a one size fits all solution unfortunately. Some systems we're able to validate externally via LexisNexis, while others with only local addresses we validate against our internal GIS. We still get a fair amount of return mail, though the largest majority of that is from receivables invoices.
-
We built an interface using Dell Boomi and the delivered FBDI. State agencies use their subsystems to send us pre approved OTP's in a specific file format. At load time, we run validation and approval workflow so these payments (invoices) are ready to be picked up by a PPR.
We also rolled out the FBDI to certain users at agencies. Supporting this has been time consuming due to the technical nature of this upload for AP staff, but service requests are declining steadily.
There are a number of things about Fusion OTP's that I don't like. I wish Oracle would provide a page in the UI where users could key them in instead of forcing them to the FBDI. I also don't like that there is no distinct id that the users can see that uniquely identifies a payee. Also, as mentioned above, address and bank account info causes many rejected/returned payments.
PeopleSoft has a much more mature solution for one time payments (aka Payment Requests). I'm hoping they will follow a similar process for Fusion in a future release.
