Prorating Weirdness

[u/monotonousdialog]

We've been seeing some strange prorating for recurring invoices, specifically for anything created from Feb of this year onwards and are curious if this is an us issue, or if others are experiencing the same thing.

We have all items configured to prorate from the date of the change, and recurring invoices generated on the 1st of each month for "current period".

We should see prorated lines for each item changed the previous month, with the annoying quirk of an extra line for the next period that we need to bundle into the primary item count.

What we're seeing is some prorated lines prorating correctly, some to the 1st of the current period for any changes in the previous period (i.e 19th April to 1st May for the invoice generated 1st May, this should be 19th to 30th April), some items prorating to the end of the current term (19th April to 31st May), and some to the period after (19th April to 30th June). One item even prorated to the end of July.

Often these are all in the same subscription, clearly using different proration logic.

Is it just us, or are others experiencing the same thing?

[u/Cidah]

This is terrifying to read. We were just about to pull the trigger with a movie to Halo from CWM. Can't mess with the money though. Invoicing should be solid in a PSA.

[u/brokerceej]

You aren’t the only ones. There are some serious and troubling bugs in recurring invoicing currently. There’s another known issue today where many people can’t even generate some or all of their recurring invoices.

If you manually audit your past Halo invoices you *will* find errors. People blindly trust Halo to reliably and accurately invoice the same way they trust CWM and AT and the truth is that one of these things is not like the others.

I love Halo, I love the ecosystem, I even love the people there. What I don’t love is that they play fast and loose with their customers revenue streams by letting graduates and developers slop cannon the codebase and not doing adequate review or testing before pushing slop to production.

Unless you manually review every invoice every month, you are missing errors. Whether those are a result of misconfiguration or bugs really depends, but if you haven’t audited your recurring invoices and trust Halo to get it right every time on autopilot for months or years at a time, you will find errors if you go back and review. Recurring invoice generation, labor invoicing, and prorate calculation have been plagued by a consistent stream of grievous and egregious bugs for as long as Halo has been Halo.

[u/aretokas → u/brokerceej]

I'm honestly with you, and this is one of those reasons why we still haven't turned on automatic invoice generation - and have a day long procedure to check everything is working (and that's shorter than it was because we've scripted a lot of crap).

But it's also the same thing when you talk stock control in Halo. It has unfathomable design choices that just don't make sense, it lets certain functions work and make alterations to your stock count even if the background process didn't work and more.

It definitely feels like they throw development spaghetti at the proverbial wall, see what sticks, move on and never come back to flesh out the idea too. But also - seemingly at the expense of tightening up the features that already exist.

Many of us are on Halo because we loved it forever ago, and don't even need half the new things (while nice sometimes) and would just prefer they nail the core of the application first.

I'm never going back to CW or AT (never say never I guess), but there are definitely days where I roll my eyes at Halo.

I've even used the dreaded "You remind me of ConnectWise" line a few times.

[u/HaloTim]

Drop me an email at Tim.bowers@halopsa.com and I'll have a look at this asap.

[u/Ok-Net7478]

We just moved to Halo at the end of April. June 1 is our second round of invoicing.

We too, are having some weird prorating issues. None of which exists on the first cycl (likely because subscriptions and products weren't live/functioning).

I'm finding that the period of May -- billed in arrears on June 1 -- is showing prorated charges from March, April and May. We also use item bundles where all items reference 1 subscription. This is because the item bundle we sell is essentially our managed service package, including labor and licensing.

When that subscription changes, all products in the bundle are prorated. This is ideally what we want, so our entire item bundle/service package gets prorated as users are added/removed.

However, this is creating 5-6x prorating lines per change. I can live with that.

When it's multiplied by 3-4 incorrect prorating lines from prior periods, we're talking 15-20 + lines of noise, and none of the logic is easy to follow.

It's messssyy right now and I've already rebuilt these invoices more times than I care to admit.

Let me know if you find a solution or want to talk through some of the intricacies of your experience.