Thanks for such an elaborate comment. Completely agree with you, that in your complex setup, shutting down WA finances makes sense. At least until we start handling Installment Payments correctly.
Actually I think we will use your setup for analysis of this issue :)

Oleg, Product Owner @ Payments team

Final part
4) The biggest issue that we can’t live with is the most recent issue related to combining all outstanding balances for a member. We sell more than 12 trips per year over a period of 18 months plus another 15 to 20 small activities. Most of these are managed by a different Admin (we have 26). If one of these Admins is slow or derelict in handling their payment processing, it can have an impact all our other activities. Also if we allowed Balances to be paid by Paypal as desired, that would shutdown the use of Paypal for anything else for that person until the 3 to 6 months pass before that outstanding payment is due and paid.

If the program could handle the complicated financial’s that go with running a non-profit travel group, we would be happy to use it. We understand this to be a difficult thing but as you can see from just a few of the problems it causes, it needs to be done right or not at all. For this reason we would like the ability to shut-off all or the following of the finacial’s until WA can handle most of the issues outlined above in a more robust manner.

1) Stop combining events and their associated financial’s. All events should be handled separately, as if they were be sold by a separate company.
2) Stop sending notes to members telling them they are due a refund or need to make a payment. Notes about payments due can already be handled by the WA reminder email process. Refunds are very specific in how they are handled by an organization and sometimes are given at all. Messages telling members incorrect info is not helpful.

PART TWO ISSUES & WORKAROUNDS
Work around's we are forced to use that cause confusion, errors and misleading information automatically sent to our Registrants:

1) Every Trip we sell must be broken into 2 phases (deposit, then balance & trip options). This is caused by WA not allowing installment payments for our small deposit amount that we want to be collected by paypal. The large much later balance payment is preferred to be paid by check, which might cause a problem with a future installment program, since we would prefer to only accept paypal for the deposit part of the installment plan. So the program would need to only allow paypal on the first installment. Alternatively it could charge an extra convenience fee for paying by installments on paypal.
1a) This process causes major confusion and frustration for our members since they see this as redundant and believe they are paying more than advertised for the trip.
1b) This causes errors and confusion with ***************** since they know it is all one trip and often demand to record all payments in one event if that is the way the payment is made by the trip participant. This is how it is recorded in the spreadsheet. Since the deposit phase only asks for a small amount, it shows up as paid in full for the trip but the major balance is still owed. This confuses some since they know their official payment tracking says they still owe more money.
1c) This causes mismatched information in the 2 event descriptions since the website views these as 2 entirely unrelated events. Corrections are often made in one event but not the other phase of the event.
2) We can not offer the allow paypal on the Balance payment since as soon as the person registers for their balance to get a total remaining due for that trip with options, it becomes an outstanding balance that WA keeps telling members they owe even if it isn’t dues for 90 to 270 days.
2a) If we allow payment to be made by check or paypal, the website will demand they pay this entire amount if they attempt to pay for something else via online payment.
2b) If a check it sent in for $1000 but not yet recorded by the **************** and the person attempts to register for one of our small $30 daily events, it demands they pay all outstanding balances now or they can’t register for that small limited attendance event.
2c) Depending on how many trips they are registered to attend they could get a demand to pay an extra $2000 to $15000 above the $30 they need to pay online. We don’t want these funds until it close to the date the payment is due. If they cancel, we would have lost any paypal fees and also now have to handle a large refund, 6 months early.
2d) Because of this major problem in step 2c) we had to abandon our plan to allow paypal on balances but just yesterday had an issue related to a deposit since it was paid by check and not recorded yet when a person tried to register for a very small $30 purchase.
3) Errors in the total financial consolidation component send notes to our members that they either owe major amounts of money they know they already paid or are due major refunds that they aren’t really due.
3a) Many of these accounting errors are caused by the difficult task of recording registration of couples on trips. They need to sign-up as a member with a “guest” and then the admin needs to break them back into individuals to ensure all airline tickets and such things are properly handled.
3b) Workarounds to handle this have been reasonably made but the major issue is how the program tries to handle the accounting of the second payment by the now individual registrant without a guest. Most common error is it claims they are now due a refund.
3c) Trying to cleanup these errors is not easy and therefore difficult to teach. Depending on how the error was created, deleting them can either work or cancel the payment that was really made or remove a person from a trip. The webmaster is forced to do this and he/I don’t have real knowledge of how the error got there so it is always a crap-shoot as to whether the clean-up will work or corrupt actual data within the event.

This is an old posting but it appears still active. I’m only supporting turning off most of your financial reporting features because you refuse to accept how important it is to your members to have a top notch reporting system. What you currently have causes massive numbers of work-around's, errors and confusion for our members and administrators.

As requested first here is our process:
1) Members register for a trip (event) that cost between $1000 and $6000. They only pay a deposit between $150 to $500 to hold their spot. This deposit is refundable until about 90 days before the event but with a minimal $30 to $50 cancellation fee. The deposit payment is payable by either check or paypal.
2) The trip (event) leader records the payments in an excel spreadsheet by registrant and weekly sends the spreadsheet and checks (if any) to our Treasurer to record into our by event (not participant) Quickbooks accounting system.
3) Role of the website is to manage our limited trip spots (pillows), describe the trips and handle registration and selection of trip options.
4) In its current state the ** financial’s can not be used for primary financial accounting due to numerous issues to be addressed below. It serves as a QC report and collector of trip payment notes.
5) About 90 days before the trip leaves the recipient must either make payment of their balance (between $850 and $4500) or cancel from the trip.
6) We would prefer to allow them to make this payment either by check or Paypal but issues documented below force us to only allow payment by check.
7) Trip Coordinator records all these payments in the spreadsheet again and sends to treasurer to record in Quickbooks for the event. Website is used to help reconcile payments but not for processing in its current form.
8) The financial processing of refunds due to cancellations is all handled outside of ** since it doesn't have a way to handle cancellation fees that are variable and can be as much as 100% of payment. This is a major cause of errors since once the registration spot is canceled ** claims they are due a refund that it thinks wasn’t paid at all or not paid in the proper amount.
9) Final trip payment reconciliation is done outside ** and ** is only used for supplemental data.
END OF PART ONE PROCESS

Thanks for posting. From our perspective invoice is just a mechanism to distinguish between registrations that were paid online from those that weren't. Do far I can't think of a way around this. If you do not record payments, how do you track and reconcile your cash receipts and your event income?

Can you elaborate - what do you find onerous about applying payments to invoices?

The typical process is like this:

1) Find the invoice, go to its details (this can be done from the list of invoices, from a particular contact, from event registrations)

2) Click on Record payment

3) If desired you can add information about payment tender etc. Or you can skip this.

4) Click on Save.

So recording payment for an invoice is two button clicks.

For events, we encourage our members and quests to prereqister online. Our meeting price is structured to encourage preregistration. So most do preregister. Some prepay - some do not. And for those that wait and pay at the door, we simply collect at the door.

We do not want a billing and/or A/R process which generates an invoice which we must later apply what we collect at the door or cancel. We simply do not have that sort of operation. Ours is a professional association but not like a country club where there is a contractual obligation to pay dues.

We do not want invoices generated for our events and we do not want to have to go apply a payment to an invoice later (by the way - that is a very painful process in WA and part of the reason why we do not want to do this).

With your last update, now we have invoices being generated that are not cleared (partly because it is such an onerous process) and our members are starting to no longer use the site for pre-registering for our events - just the opposite behavior from what we want.

To answer your questions.

1) we accept on line and off line payments

2) We do not want to generate invoices to our members - ever. So we will never track an unpaid invoices. For our purposes - for events - ie meetings and training events - we use WA for preregistration and to hook into paypal for those that want to prepay. At the event, we will bring with us a print out from paypay (or WA) showing who has paid for the event and use that at the door to determine who we need to collect from at the door.

3) Our member registers for the event. The system offers the opportunity to prepay. if they choose to prepay, WA interacts with paypal for collecting the funds. Rather they prepay or not, WA captures the registration event and we are done.

4) We allow payment in advance and we take payment at the door.

5) I think I answered this already in #3.

I think the simplist way to say this is - make an option to turn off the invoice generation process. Provide an option that allows for registration with no collection or A/R consideration. Allow for payment of the event - but do not require payment.

I am happy to supply any additional information. You may email me at vp_finance@pmi-charleston.org or call at 843-745-4065.

So you know - this is having such a bad impact on our membership and operations - and because we can find no soluition to turn off the invoicing process - we are actively looking for a solution to replace Wild Apricot. We encourage you to provide an answer quickly.

Thanks, Alan Gosnell

I know we are getting a ton of complaints about all the emails our members get now with each transaction. Wouldn't it make more sense to have a "Print Invoice" button on the "registration pending" email (whether event or membership)?

I believe this situation is affecting our account. We use Quickbooks for all of our accounting and while we have considered invoicing through WA, we are not ready to do that yet. We accept on-line payments but through a separate cart since you do not link with FirstData.

I just realized that a member can go into their profile and generate their own invoice and attempt to pay it, even though I have on-line payments disabled. If we aren't using the invoice feature, there should be away to disable it and should also be able to determine whether or not we want our members to have that capability.

Thank you!