57 lines
No EOL
3.3 KiB
Markdown
57 lines
No EOL
3.3 KiB
Markdown
# Invoicing Comeback
|
|
|
|
As of today (Dec 23) the invoicing process is a mess. It's terribly manual, not elegant at all, it's causing a lot of troubles and is putting the company at risk.
|
|
|
|
Everyone agrees on it, yet we still need to put a solution in place. The Data Team has been asked to step in and help. This repository aggregates contents on this issue.
|
|
|
|
## Content index
|
|
|
|
- `FW Payments and Invoicing process.msg`: some contents sent by Elaine, including Excel sheets they use to merge and process data.
|
|
- `step_files`: the Excel sheets mentioned above.
|
|
- Invoicing flow chart: a flow chart built by Ben C. with the different steps: https://miro.com/app/board/uXjVMirYfDg=/
|
|
|
|
|
|
## My notes on the video
|
|
|
|
My notes when watching through the video Ben C. recorded with the Finance team.
|
|
Link to the video: https://guardhog-my.sharepoint.com/:v:/g/personal/ben_cotte_superhog_com/EXMpEnpXVmpErLmDedCxpyEBMbYKS4lezEp_gihbbSfsxg?e=eVFhxM
|
|
|
|
- Jamie has the task of calculating the waivers (can this be divided into a subprocess?)
|
|
- Data is exported out of PowerBI and Acquired and "validated". There are inconsistencies between both sources and the team manually fixes them.
|
|
- What are in the inconsistencies? Why do they happen?
|
|
- If Acquired is the source of truth, why bother export the PowerBI data?
|
|
- Which PowerBI is it exactly? What exact table gets exported?
|
|
- With this, waivers are calculated and payments are reconciled.
|
|
- Some manual information needs to be obtained through the dashboard
|
|
- Which?
|
|
- How can we get it out of the backend without having to go through the UI? Can I make a nice query to fetch this out instead?
|
|
- Info also gets manually searched for in Hubspot and the Acquired dashboard.
|
|
- So, what's not really in PowerBI?
|
|
- Manual refunds
|
|
- Chargebacks
|
|
- Errors 262 from Acquired (PowerBI considers it as paid even though it isn't)
|
|
- Sometimes the payment is simply not in Dashboard at all, so it doesn't appear in PBI.
|
|
- Manually convert the currencies (Can I lookup some small excel wizardry to make this simple for them???)
|
|
- There are Payment Requests that get manually generated by the Customer Service team in Stripe and sent to customers out-of-process if Acquired fails.
|
|
- Records in Stripe about who the host is, what the booking is, need to be checked manually from the UI
|
|
- From Hubspot
|
|
- Get the new clients and pricing structure there
|
|
- Client names in Hubspot and Dashboard are different
|
|
|
|
|
|
Some random thoughts:
|
|
- I feel a lot of negativity in the meeting. Everything is deemed hard and not doable. "We are doomed and that's it."
|
|
- Would all of these PBI exports be simplified by having direct queries to the databases?
|
|
- It feels like Dashboard is not 100% perfectly synced with the Payment Providers?
|
|
|
|
|
|
|
|
Fronts:
|
|
- Quickish
|
|
- Ease data export from dashboard with tailored queries
|
|
- Formalize things and win spreadsheet agility by simply formalizing and documenting things
|
|
- Somehow make nicer exports from Acquired and/or Stripe
|
|
- Longish
|
|
- Remove manual payments from process limbo. We need some degree of organization around there, even if the first version is just a well maintained shared spreadsheet.
|
|
- Single payment processor
|
|
- Integrate payment processor data into a database of ours. Dashboard backend if it makes sense, DWH if it doesn't. Join with Dashboard data. |