RE NXT and Merchant Services

Question

When using the web view donation form if the address accelerator is used it does not provide a field for Apt, Ste. or Unit #. If that information had been entered once the address accelerator is used the information is lost. Has anyone else experienced this issue? I see many donations come through with incomplete addresses.

Consequently, I have to take time to verify the address as to which entry is correct - the donor or the data base information. Usually it is our data base information that is correct.

Carlene Johnson · Answer

Hi @Barbara Sauber - happy to chime in to help.  I'm cutting and pasting a bunch of information from an idea I have in the idea bank.

Yes, you're definitely not alone on this one, it's a common complaint and honestly a frustrating one. And just to be clear on terminology: what you're running into isn't AddressAccelerator, it's a completely different tool. This doesn't have anything to do with Blackbaud Merchant Services either, but rather Blackbaud's forms. What's actually happening is that Blackbaud uses a geolocation/places autocomplete service (like Bing Maps Autosuggest) for gift forms, event registration, constituent forms, or manual record entry.

That tool is built for map searching, not for validating mailing addresses. As a result, it frequently:

* Fails to recognize valid residential or organizational addresses
* Suggests unrelated businesses or far-away locations
* Struggles with international formats
* Doesn't standardize addresses to USPS or global postal standards
* Creates friction for donors, registrants, and staff
* Introduces inconsistent or undeliverable address data into the database

For a fundraising CRM, accurate and standardized addresses are essential for stewardship, tax receipts, segmentation, and donor communication. A mapping autocomplete just isn't built for that job.

The idea I submitted to the Idea Bank asks Blackbaud to replace the current geolocation-based autocomplete with true postal validation — USPS CASS-certified for U.S. addresses, and a global postal dataset for international ones — applied consistently across every address entry point: RENXT Standard and Optimized Donation Forms, Event Registration Forms, Constituent Forms, manual entry in NXT, Membership Forms, and any future forms or workflows that collect addresses.

The benefits are pretty clear: cleaner data at the point of entry, fewer returned mail pieces and wasted postage, a better donor/registrant experience, higher conversion on forms, less reliance on batch cleanup, and more accurate reporting and segmentation.

Barbara, your current addresses are very likely more accurate than what's coming in through the new form, since that process strips out Apt, Ste., or Unit #.

In the meantime, you've got a few options related to Online Data Review:

* Review and match all transactions — manual review of everything before it moves to batch. Full oversight, but it'll slow down processing considerably. Worth it if you need hyper-accurate data or handle sensitive information.

* Review transactions with unmatched constituents only — lets the system auto-match high-confidence constituents and only flags unmatched ones for review. Faster, but it won't catch an address mismatch on an existing match — you'll end up with two "Home" addresses, with the new one marked Preferred. You'll need to run audit queries periodically to sort those out.

* Set forms to bring in new addresses as "Online Form Address" type, then review periodically against the existing address on the record. This is the system Elizabeth Johnson follows.

* For larger organizations, building an automated solution with Power Automate may be worth exploring. Austen Brown, you might have some thoughts on that approach.

Options 2 and 3 can work fine for smaller organizations, but they're not realistic at scale for larger ones.

One last thing on AddressAccelerator: Blackbaud is working to bring AddressAccelerator into Web View — it's currently a Database View-only add-on, so not every client even has it. When you run it today, it adds attributes directly to the record flagging the specific issue with an address. My concern is that when it comes to Web View, it'll follow the same pattern as Address Finder there now: results surfaced in a list inside the Data Health tool, but not written to the record itself, and not something you can query or export against. If that's the direction it goes, we lose the ability to actually act on that information at any scale, which would be a real step back from what AddressAccelerator gives us in Database View today.

Barbara — if any of this resonates, please go vote on these related ideas. Votes are how Blackbaud actually prioritizes what gets built:

* Create better address validation for NXT forms — directly addresses the unit/apartment number stripping issue you're running into

* Address Finder needs AddressAccelerator Footnote — speaks to the concern that Address Finder results aren't writing back to the record in a queryable way, which is exactly what worries me about how Accelerator might land in Web View

* Replace geolocation autocomplete with postal validation — my idea on swapping the current mapping-based autocomplete for true CASS-certified validation

I hope some of this lengthy response makes for some good discussion and more votes in the Idea Bank!

Crystal Bruce · Answer

Hey @Barbara Sauber I see it has been a few days with no response from the community yet. I'd love to tag in some All-Stars @Carlene Johnson @Austen Brown @Karen Diener to see if they have any insight to offer!

Crystal Bruce · Answer

Hi @Barbara Sauber - you posted this in the Blackbaud CRM community, so I moved it over to Raiser's Edge NXT for answers. Thanks!