our Billing really depends on the type of products purchased (or complexity of the deal). Currently Billing Batches are assigned per Account. But we'd like to assign Billing Batches per subscriptions
Example: Support subscription - is paid annual up front - so that can go out as soon as order is processed no issues. But a second order for professional services - is split into multiple payments, that are dependent on customer acceptance or milestone. Upon processing the order - we know what the payments are split (30/20/20/20/10%) and we may have target projected dates in the SOW that each of those may be invoiced on. BUt we can't invoice those split payments until the cusotmer actually accepts each milestone.
So A. Splitting the inovice into these payments %, and giving them dates - once you post the invoice - it posts for all 5 payments. We need to have the ability to put this subscription in a seperate "customer acceptance" billing batch - that will have to be hand held/coordinate with project management to confirm that we have the acceptance and cand send the next invoice out, or if not,need to edit the invoice date and push the date out.
** this also spurrs another idea - for split invoicing, to be able to post the invoices individually.
We have a deal, to be split invoicing for 30/20/20/20/10%
but when we split the invoice, it posts all 5 invoices. We only want to post the first one (as it's due upons contract signature) and leave the other ones as draft - so that as we pass the milestone and/or get the cusotmer acceptance we can then post those invoices.
right now if we split it and post it. we dont' have a check & balance in place to ensure the other inovices do not go out until the customer accepts the milestone. And also - we may need to push the invoice date out if the project is delayed or not.
I've been experimenting with the REST API's BillingPreview request, and I've noticed the InvoiceItem objects that it returns do not include the productId foreign key for the associated product (which the SOAP API's InvoiceItems do include.) It would be great to have a definitive reference to the product that InvoiceItem is associated with.
Side note: The REST API's BillingPreview InvoiceItem objects do contain the productName, so perhaps the table join is already being performed, and adding the id would not be terribly difficult?
We would like to have the opportunity to not send any automatic reminders on specific invoices. For example, if we have an ongoing discussion with a customer regarding a specific invoice we would like to silent that invoice so that no further reminders are being sent on that invoice. However, the customer may have other unpaid invoices which should recieve reminders. In this case you do not want to change the customer's communication profile, but only the invoice which is under dispute.
Zuora recommending setting up communication profiles to filter these customers. But the issue is not the entire customer account nor the entire customer's outstanding payment, but only a specific invoice. If we would send an automatic notification regarding service termination that would harm our relationship with the customer. Basically, it would be a good idea if you could turn off notifications on specific invoices rather than change number of notifications on the customer account.
We would like the option of creating a proforma billing that we can send to our customer in order to request payment in advance of recording an actual bill. The proforma bill does not generate a GL transaction but is visible on the account somehow so when payment is received we can identify the account.
Currently, the invoice split can only do percentage split. It would be great if we could have the option to split invoices by dollar amounts, it would save a lot of time especially when have to have all percentage splits equal to 100%
As of today, we do not recieve any notification if we post invoices and the deliver of email fails. This could mean that our customers never recieves their invoices. In addition, we would have no idea if any invoices fails to be delivered.
For non-English speakers, the country field in payment pages should be in Alphabetical order.
When passing in a locale to the payment pages that's not in English, Zuora should display the country drop down in alphabetical order. Currently it doesn't which leads to poor customer experience.
Resultant non-sorted country drop down list
Customers who speak French, German etc shouldn't have to have in their heads what the english name is, then translate to the german name for example when choosing their country from the drop down. E.g. Germany begins with G in English but D (Deutschland) in German, therefore Deutschland should appear in the 'D' part of the drop down. Likewise Spanish customers should be looking at the 'E' part of the drop down, not having to scroll much further down for 'S'.
Currently when payment runs are completed you are shown the number of and amount of unprocessed payments. I would like a report that showed me what invoices those were or what accounts those belong to. That would help me to see what is going on with those accounts and why payments are not processing.
Merchants want the ability to check if a credit card already exists in the system.
An API that results in a true/false will give the merchant the abilty to decide a course of action.
Due to European portability rules, merchants need to know the credit card issuing country
It would be helpful to have this information returned in Zuora HPM response or in payment method transaction log.
Zuora really needs customer account statements. These should be able to be pulled at any time without running an invoice. It would combine charges, payment, and balance information in one place. Customers often request at least a year's history. The workaround to use a custom invoice is clunky and doesn't really cut it. Every other accounting system that I have used has this capability.
We have a problem with the "Hosted Domain" required field on the Hosted Payment Page configuration page. This limits the payment page to only one domain, which poses increasing developer overhead for us, because we have multiple different test environments, which should share the same Payment Page. Instead we have to create a new payment page for every new test domain we want to use.
This does not scale, as we have to update an increasing number of payment pages every time we want to roll out a change to the styling or other functionality of the page that needs to be changed through the Hosted Pages settings.
This is also preventing us from using developer workflows like Heroku's Review Apps, which spins a new instance of our application on a custom subdomain for each new feature we're developing.
Thus we'd like to request for the "Hosted Domain" configuration field to be upgraded to support adding wildcards and multiple domains, or even turn off that check entirely. This would greatly help us in our Zuora developer and testing workflows.
We'd really like the ability to be able to set these default settings for each new bill run that is created. In particular, we would like Do not email invoices with 0 total enabled by default, as we run the business risk of sending confusing 0 dollar invoices if it stays unchecked.
Create account currently accepts just the raw credit card details or a HPM id. It would be ideal to be able to create an account with an Apple Pay payment method in an atomic create account call.
Today the only way to create an account with an Apple Pay payment method is to use Actions and Objects. Any merchant that's gone the route of using the atomic/friendly create account will face considerable effort to add support for Apple Pay.
Need the ability for ZUora to send bounce back notification to tenant's admin users whenever an email is send to the customer but the email address is invalid.
When we email an invoice to a customer, a box pops up to confirm the email address for the invoice delivery. It gives an option to "Include Additional Email Addresses". However, when sending a payment receipt this option is not available. It would be nice to have this in case an additional email address is also needed for receipts.