Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paying expenses to payees who don't manage their own profile on the platform #5894

Open
1 of 4 tasks
viktorix opened this issue Aug 23, 2022 · 10 comments
Open
1 of 4 tasks

Comments

@viktorix
Copy link

Who is your user?

All collective admins that are using the expenses feature of OpenCollective.

What are they trying to achieve?

I chose OpenCollective for our fundraising because we want to provide financial transparency in our non-profit organization, which includes both contributions/donations and expenses. This helps build trust with our community and helps contributors see how their money is being spent. In order to do this, we need to be able to add expenses easily to our collective's page. We can't invite companies to be "payees" when adding an invoice. For example, we use DigitalOcean for hosting/infrastructure. They charge us automatically every month. We can't invite them, but we need to track that expense.

How are they currently doing this?

This conversation started in Slack and Alanna Irving mentioned a workaround that some admins take when they need to submit an invoice, which doesn't sound ideal for OpenCollective to have fake accounts:

It’s tricky because the person submitting the expense is not an AWS employee so it’s weird for them to own an OC profile for AWS, which they need to do to have it as the payee. So in this case, the official line is to use the Collective itself as the payee, as Viktor has. However lots of people do create such dummy profiles so it’s an unsolved issue on the paltform.

It sounds like a problem worth solving to eliminate the need for fake accounts.

Possible solution

We need a way to have something like a custom payee option, which requires no invitation. We simply select the custom payee option, which reveals a text input field. We enter the payee's name, and that's it. No invitations to send.

A bonus would be the ability to save custom payees, so we could select payees we've added in the past. This would save a little time when creating an expense.

How well understood is this problem?

  • Surfacing: if you feel this is a seed of an idea that needs to be researched.
  • Understanding: if you've done some research and feel it is already well understood and ready for shaping.
  • Shaping: if you feel a solution is clearly defined and can be made into a pitch (read more about shaping)
  • Pitching: if you feel that it is ready to be presented for prioritisation (read more about pitching)
@alanna
Copy link
Contributor

alanna commented Aug 24, 2022

The way this is done now is either 1. select the Collective as the payee (doesn't as accurately show where money goes), or 2. someone owns a dummy profile for a company they don't work at (search 'Amazon' or 'Shopify' or any other common vendor to see examples). Neither seems great.

@BenJam
Copy link
Contributor

BenJam commented Aug 31, 2022

I have to say that I dont really understand the approach here. Right now expenses like this are borne by one member of the community, which is this reimbursed through Open Collective.

If (in this example) DO is the payee, is the implication is that they have a billing relationship with the host, or the platform?

A hosts we are interested in doing this in the future, as hosts may be able to provide discounts to member projects for common services (DO hosting being one of them) but many providers do not model their billing separate from there service provision, that is they do not distinguish between who is the bill payer from who has access to the configuration for that users account.

Hosts wont (in my opinion) want to place a bottleneck and security risk on their member projects so, long term, I'm not sure this would work. Maybe i have the wrong end of the stick?

@znarf
Copy link
Member

znarf commented Aug 31, 2022

Personal experience, using the platform to pay accommodation and caterer for the retreat: I ideally don't want the trouble of having to invite the providers to the platform.

I already have an invoice, I have a recipient bank account, I just want to enter the details and move forward with it. Involving the recipient is a lot of friction and a loss of time.

I ended up creating Organizations for the recipients that I'm managing myself :-/

@viktorix
Copy link
Author

@BenJam you're looking at this the wrong way. This is purely for recordkeeping. Financial transparency requires both income and expenses to be made public. We can't do that with the current system. This has nothing to do with the actual payments. In our case, transactions already took place and we simply need to make them public. DigitalOcean was an example. We have legal/gov fees, a mailbox, multiple SaaS subscriptions, etc.

Open Collective shows our "budget" yet it's not accurate because our expenses are not recorded.

@alanna
Copy link
Contributor

alanna commented Aug 31, 2022

I think there are two separate needs that are overlapping here:

  1. Reflecting accurately the actual money movements > an expense showing the expense to the person who actually paid, as a reimbursement.
  2. Telling an accurate story of what a Collective is spending money on > you want to show that $x was spent to different vendors to show what you pay for servers, or food, or whatever expenditures make up the budget story.

There are also cases where they are actually the same and there's no reimbursement, for example BWT is an OCNZ Collective that regularly pays a printing company to print books. We've connected the host's debit card to the publishing system and it gets automatically charged by Lulu, then once a month we process an expense (like this) to reflect the correct balance change. We have to do it this way because Stripe Issuing (virtual cards) are not available in New Zealand, and the publisher only accepts credit card payments. The money goes from the Collective direct to Lulu, but we don't need to actually pay it via the expense as it's already been paid, and Lulu won't be willing to interact with the platform to manage their profile as the expense payee.

@alanna alanna changed the title Custom payees without invitations for invoices Paying expenses to payees who don't manage their own profile on the platform Oct 12, 2022
@alanna
Copy link
Contributor

alanna commented Feb 17, 2023

One of the key blockers on this is about tax form requirements. If it's an invoice expense to a US host, and the payee isn't submitting it themselves, it will not be payable because the w9 has to be filled out by the actual payee.

@viktorix
Copy link
Author

Why not allow hosts to report expenses without assigning a payee profile/account? The existing process could remain, but you could either add a new process "Report an expense" or add an option in the existing process (a checkbox?) to report an expense without payee account.

Most of us, I assume, want to show money in/out accurately without the need for full accounting features. We simply want contributors to see where money is coming from and where it's going.

@alanna
Copy link
Contributor

alanna commented Feb 20, 2023 via email

@Betree
Copy link
Member

Betree commented Mar 30, 2023

Another request for this: #6618. In there @xdamman suggested:

  1. Go to https://opencollective.com/citizen_garden/expenses/new
  2. Big surface area to drag and drop a PDF of an invoice (or a picture of a receipt)
  3. Enter description, total amount, Pick: pay the vendor directly (vendor name, IBAN or paypal) OR reimburse me (your name, IBAN or paypal) DONE
  4. Thank you. Your invoice/receipt has been submitted to the "Citizen Garden Collective". As soon as it is approved by one of the admins (admins' names), it will be processed by their fiscal host (All for Climate ASBL/VZW). Please leave your email address to be notified when it is paid.

I think this should be considered for prioritization next sprint, at least for speccing/design.

@Ornanovitch
Copy link

We have the same need in my organization, it would be so much better for transparency

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants