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

Ability to Invalidate a tax form #7134

Closed
Tracked by #7346
Betree opened this issue Nov 29, 2023 · 2 comments · Fixed by opencollective/opencollective-api#10065 or opencollective/opencollective-frontend#10347
Assignees
Labels
api Issues that require some work on the API (https://github.com/opencollective/opencollective-api) complexity → medium feature frontend

Comments

@Betree
Copy link
Member

Betree commented Nov 29, 2023

This year, OCF got some of its expense payees flagged by the IRS for giving incomplete information in their tax forms. When that happens, the fiscal host needs to reach out to the payee and ask them to re-submit the form.

Ideally, they should be able to provide a message when invalidating. The API would then:

  1. Mark the current tax for as "INVALID" (new status)
  2. Send an email to the payee, with the custom message from the host
  3. Send reminders to the payee

Related

@Betree Betree added feature complexity → medium api Issues that require some work on the API (https://github.com/opencollective/opencollective-api) frontend labels Nov 29, 2023
@iamronen
Copy link
Contributor

This seems like it introduces potentially risky complexity:

  • Do we need to keep the "invalid" form on record?
  • Do we need to add this status to the navigation, status column, filters?
  • Are we going to have both "expired" and "invalid"?
  • Are there going to be two tax forms on record for the same payee - one invalid and one valid?

From the examples we have from OCF do we know what was incomplete?
Can we avoid this altogether by properly validating the form (now that we have full ownership of the process)?

@Betree
Copy link
Member Author

Betree commented Feb 20, 2024

Do we need to keep the "invalid" form on record?

Legally speaking, we'll surely have to keep this record. As evoked in #7218 (comment), the way I'd approach any editing functionality for tax forms would be to create a new entry and archive the old one (immutability). This is actually a requirement from the ESign act in the US: your system shouldn't let people edit the data for something they've signed in the past (see #7220 (comment)).

Do we need to add this status to the navigation, status column, filters?

Our legal documents already have a requestStatus column accepting REQUESTED/RECEIVED. Adding a new status there would make sense to me.

Are we going to have both "expired" and "invalid"?

I would make the distinction, yes.

Are there going to be two tax forms on record for the same payee - one invalid and one valid?

Yes, or even more if the tax forms get invalidated. I'd say there should only be one RECEIVED (=VALID) at all times though, submitting a new tax form should mark all the previously submitted ones as expired.

From the examples we have from OCF do we know what was incomplete?
Can we avoid this altogether by properly validating the form (now that we have full ownership of the process)?

I don't have the exact cases in mind anymore, would be great to ask them now that the process is still fresh in their minds. It's possible that better form validations will help prevent some issues, but I don't think we'll be able to catch all of them: a typo in your fiscal ID number for example is something we can hardly prevent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api Issues that require some work on the API (https://github.com/opencollective/opencollective-api) complexity → medium feature frontend
Projects
Status: Done
2 participants