any important information being passed by Excel is a travesty I think that's putting it mildly. A major issue with using Excel files for data transfer is, to p

any important information being passed by Excel is a travesty I think that's putting it mildly. A major issue with using Excel files for data transfer is, to put it bluntly, the lackadaisical way people treat Excel files. They are passed around and edited. Passed back once edited. Passing them around creates copies of them. They get goofy names as people try to manage the multiple editors and editions. There's no verifiable authority for the source or latest version of the data. None of the data or its state is externally verifiable. We've all seen where this goes south very quickly; we even have a meme for it: the FINAL FINAL FINAL suffix that gets appended to the filename. I suspect this is why/how zombie debt, as described by Oliver, gets resurrected: data quality issues: debt that is accidentally (or on purpose, to make another/recover a quick buck) sold again when it shouldn't have been. And the original owner of the debt, once sold, isn't interested in keeping track of it (they've already written it off). Some of the issue is that there are multiple parties involved. Real estate has title records as one way to solve this, which isn't necessarily a final solution (thus the existence of title insurance), but without even something resembling a centralized and agreed upon record of the history of the debt changing hands, it's impossible to reliably know anything about it. Excel files exacerbate that. Further down in these comments, AstroJetson says that to forgive debt, they "they just delete the Excel file it's in". I find this to be a reasonable possibility for how this is handled. But deleting a file received from some other party doesn't make the file disappear. It's perhaps still in an attachment somewhere, in the sent mail folder, on the computer of the sender (perhaps moved to a "Sold Debt" folder). None of this is necessarily solved by transfer methods like EDI or HL7, except for what amounts to a barrier to entry to access the data and make it available to begin with. EDI is a solution for purchase orders between Walmart and suppliers is because 1) there's often a limited number of parties (two) involved with the data, 2) Walmart is always one of the parties (so it is effectively centralized), 3) the data itself is verifiable against other, trusted sources like accounts payable and accounts receivable. It's also going into a system that has automation components. The people who are buying debt information and receiving it via Excel spreadsheets are just going to go over it by hand and call/contact people on it. It's going into some massive computer based process and generate reports for dozens of different departments like the data being transferred via EDI at Walmart is. This is where someone mentions using a blockchain or git to track the way the debt changes hands and its current state. This would be a fine suggestion if it wasn't in the interest of the debt buyers/sellers to keep the system shitty with little visibility/oversight so they can take advantage of debtors and other debt buyers any way they can.