1. NEVER format a date when you can work with it as a date. Formatting is for people, NOT for computers. Internally, the date is NOT stored as a string. It is stored as a double precision number. The integer part is the number of days since Dec 30, 1899 and the decimal part the the elapsed time since midnight. Negative numbers are dates prior to Dec 30, 1899. As was pointed out, formatting a date turns it into a string. That will make it act like a string so 24/03/2020 is > 20/02/2022 and will sort after that date as well as comparing later.
2. If you are creating an SQL string rather than using a querydef, you will need to format your date BUT, you will need to use either the unambiguous #yyyy/mm/dd# or the US standard of #mm/dd/yyyy#. In your querydef, you are referring to a bound control. Because the control is bound and is known to be a date, the query engine will be working with a double precision number. It will NOT be working with a string so there is no ambiguity. When you format a date and convert it into a string #dd/mm/yyyy# and #mm/dd/yyyy# can be ambiguous so SQL Server ASSUMES #mm/dd/yyyy#. That is why you can't use the dd/mm/yyyy format, ever in a query. In addition, if you are ever using an unbound control with a date and referencing it from the QBE, add a date format to the format property of the control. This tells Access that you expect the control to contain a date. That way it stores the data as a double precision number rather than a string.
3. NEVER use Now() as the default value for a date unless you actually want a time component in the date field. Bill Date does NOT need a time component so you should be using Date() rather than Now() to eliminate time because that is also causing a problem for you. arnel explained how to get around it. He is really good at providing band aids. I suggest that you actually fix the problem. To fix the problem, change the default to Date(). Then run an update query that replaces the date+time with just date. Use the DateValue() function to do this.