As a sender:
1. use a repeatable, automated process that will always generate the same format. Recalling the settings (delimiter, line ending, file type) from memory to export data from Excel is unacceptable. Write, AND FOLLOW, the process if necessary; automate it if possible.
2. Include meta-data with the exported data if applicable. When it was generated, who generated it, who the intended recipient is, and/or location to find information about the format. If you’re receiving the data 2nd hand and have questions, who do you ask?
3. Occasionally consume your own data. If you can’t consume it, how can you expect someone else to? Providing the process to consume the data, even if it uses a different language or program, speaks volumes and can reduce questions.

As a receiver:
1. Don’t trust the format specification to be accurately followed by the sender. Two senders may interpret one standard differently.
2. Don’t get mad when the format or data is invalid. Whoever provided the data may be new to the job or may be overworked. Not to mention, your words may come back to haunt you.
3. Reuse existing import tools. Rolling your own code to import a file can introduce errors, especially when someone else has already done all the hard work. FileHelpers for .NET can handle CSV, quoted fields, fixed width, fixed width with variable record types, data type conversion, and more. Chances are, the pre-built import tools already have efficient fixes for unexpected complex import problems.