what is the difference between system and acceptance testing as a tester? what extra test cases will acceptance testing produce?

I read some of the previous answers of similar questions on here but i am not satisfied. So both System and acceptance testing evaluates the system against the requirements.

Acceptence testing is for the users/customers and they decide if they will accept the system. But acceptance testing is allso for us testers... here i am abit confused of what extra test cases i will produce in the acceptance-phase that i did not already produce in the system phase?

It's important to know that all testing phases have overlap. This is done by design both to cover any gaps in the previous test phrase, but to also test the same thing from different points of view.

System testing checks the complete system against a list of requirements. Acceptance testing checks the complete system against what the user wants, possibly by actually using it. And as we all know, what the requirements say and what the user wants can be two different things. The important difference is who is driving the tests: the developers or the users.

Wikipedia has a good explanation about the difference between User Acceptance Testing and System Testing.

User acceptance testing (UAT) consists of a process of verifying that a solution works for the user. It is not system testing (ensuring software does not crash and meets documented requirements), but rather ensures that the solution will work for the user (i.e., tests that the user accepts the solution); software vendors often refer to this as "Beta testing".

This testing should be undertaken by a subject-matter expert (SME), preferably the owner or client of the solution under test, and provide a summary of the findings for confirmation to proceed after trial or review. In software development, UAT as one of the final stages of a project often occurs before a client or customer accepts the new system. Users of the system perform tests in line with what would occur in real-life scenarios.[9]

The analogy to beta testing is a good one: in the process of using the software beta testers will run all sorts of scenarios you didn't think of. Often these will not be in the requirements. They might have been forgotten, or assumed, or too detailed, or simply not conceived of, or bugs (especially concurrency bugs).

• "The system crashed when we added the 257th user."
• "I was editing a document while someone else deleted it, and the document was resurrected. It should still be deleted."
• "If I hit escape while saving the document I get two copies of the document."
• "The text is hard to read in dark mode."

"Acceptance testing" is sometimes done by the development team on behalf of the users. The on-site customer will write up a set of acceptance tests from a black box perspective which the team will have to implement. These can become regression tests.

• "Sort 10,000 documents by name in less than 1 second."
• "All columns must be sortable both ascending and descending."
• "The site must follow sections X, Y, and Z of WCAG 2.1"

This sort of acceptance testing by the development team is sometimes a surrogate for User Acceptance Testing, or it can be done prior to UAT to ensure the software is in as good a shape as possible before being presented to the customer for acceptance.