I would say that there is no one "right" way to do this. The important thing is to have a consistent approach that meets all the requirements for reporting and recording. That in turn will need to take into account your system's capabilities/design and your data practices.
Many people will advocate your practice, perhaps advocating that the hard credit be assigned to the spouse signing the check or authorizing the credit card charge. You would need to decide what happens when you receive a check from someone who is not in the system but whose spouse is in the system (further complicated, for educational institutions, when one spouse is an alum and one is not). In this approach, you'd create a record for the spouse and connect it to the person in the system.
That doesn't really solve the "each spouse only looks like they gave half of what they gave" problem, because one spouse may give one time, and the other the next time, and then in total "each spouse only looks like they gave half of what they gave." So your reporting needs to be sophisticated enough to give a full picture of giving by the couple.
In general, the overwhelming majority of gifts from couples are made from joint assets, so neither recording the entire gift on one spouse record or splitting it between the spouse records is meaningfully more "correct".
I'm in the minority, but I've always liked the splitting method. If you received a gift from one spouse (in the absence of any information that this is intended as a gift from only that one spouse, which requires a different analysis), I would split the hard credit and give each spouse full soft credit. So if the gift was $100, I'd give each spouse $50 hard credit and $100 soft credit. That way, when you're working on recognition issues for an individual, you just look a the soft credit, and don't have to add $50 hard credit and $50 soft credit that one might add using a different approach. It has worked extremely well, whatever somewhat strident rhetoric you might on occasion hear about it being an awful practice or some such.
None of this is perfect. You might have a whole string of gifts from someone with no idea whether they're married or not, then get another gift initiated by a spouse (and typically without any idea of how long they've been a spouse). Neither giving all the hard credit to the spouse who initiated the particular gift nor splitting the hard credit is going to solve how you report that giving history.
Receipting, in my experience, often smooths these issues by receipting the couple jointly, regardless of whether you split the hard credit or recorded it against spouse A or recorded it against spouse B (again, in the absence of specific information that the gift is to be treated as coming from one spouse).
Besides receipting, and besides reporting per se, whatever approach you choose, you will need to train the people looking at the data in your system.
Since it seems like your history is giving all the hard credit to one spouse, changing to a different policy now is likely to just confuse matters, without any meaningful gain, in my opinion, my own druthers notwithstanding. You would, I would opine, want to make sure that your system is equitable, which presumably it is (e.g. assigning the hard credit to the spouse who initiated the gift, not just assigning it to the husband in a "traditional" couple).
Life would (perhaps?) be easier if there were one "right" approach, and if we had complete data on donors' marital statuses and their intentions. But that's not my experience.
What might be helpful is to sit down and decide collectively how you want giving by couples to appear in different contexts: donor histories, annual totals, giving trends, etc. You certainly wouldn't want to solicit someone as not having given this year because their spouse wrote this year's check! And then, once you decide how you want the couple to be reported, you figure out how to accomplish that within the capabilities of your system and your reporting practices.
My US$0.02 worth; the usual disclaimers apply.
Good luck!
Alan
Alan S. Hejnal (he/him)
Data Quality Manager
