People use the terms "business rule" and "business logic" to refer to the portion of your application that is specific to your application and represents the core behavior of how things are supposed to work as opposed to generic functionality that could be useful in software written for a different client/business/customer base or code that exists to support the infrastructure of the application.
Often business logic is subject to change when the needs of the customer change, so we like to put it in a special place/tier so that we can modify it as needed.
Although the term seems to imply otherwise, non-business software also has business logic. For example, a rule that states that "when a user does xyz, the application should validate something" can be classified as a business rule.
Utility code, such as parsing/processing/data access and such would not be considered business logic.
It's kind of a nebulous term and could mean different things to different people in different contexts. It's not worth getting hung up on. The general idea is to separate your application into logical portions, each of which is responsible for something specific. How exactly this is done is something you learn from experience and working on well-designed large applications. But there aren't any hard and fast rules. Ask three good developers and you'll get six opinions.