How to filter out Scalar Valued User-Defined Function usage from SQL Server Audit Data?
There are a few options that I was able to get working. All of the options deal with variations of filter predicates. NOTE: you must disable the Server Audit in order to make changes, and then re-enable it.

First, the most generic approach is to filter out all Scalar UDFs. You can do that by using the class_type audit field. The documentation indicates that this field is VARCHAR(2), but it doesn't allow specifying a string. However, I did get the following to work:

ALTER SERVER AUDIT [servAudit]
WHERE ([class_type] &lt;&gt; 20038); -- EXECUTE Scalar UDF


(more info on that investigation here: Server Audit Mystery: Filtering class_type gets Error Msg 25713)

The next most generic approach is not an option since it was stated that this is a vendor-supplied database and hence no changes can be made. So I will cover that last.

The least generic approach (but one that definitely works) is to filter out the specific function name:

ALTER SERVER AUDIT [servAudit]
WHERE ([object_name]&lt;&gt;'function_name');


Or, if multiple names:

ALTER SERVER AUDIT [servAudit]
WHERE ([object_name]&lt;&gt;'function_name1' AND [object_name]&lt;&gt;'function_name2');


While not very generic, this approach should be fine since the number of functions to filter out should be fairly small, and it won't be very often that new functions are introduced.

Finally, to others who face this situation and are not restricted from making changes: you can place functions into their own Schema and then filter out just that Schema. This is more generic than filtering out the functions individually. Assuming that you create a Schema named fn and place the function(s) into it:

ALTER SERVER AUDIT [servAudit]
WHERE ([schema_name]&lt;&gt;'fn');




ALSO, regarding the following two comments in the question:


  Unfortunately, SQL Server doesn't allow relational IN operator (probably because it doesn't want to query every time it has to write to the audit log).


and:


  We would like to avoid writing a stored proc which hard codes the object_id in the WHERE clause


The IN operator isn't the issue. True, it is not supported, but it's just shorthand for a list of OR conditions. The actual issue is the use of T-SQL. Only literals &mdash; strings or numbers &mdash; are allowed. So you wouldn't have been able to execute a Stored Procedure anyway. Nor can you use the built-in functions.